Re: [Intel-gfx] [PATCH 29/29] mm: shrinker: move shrinker-related code into a separate file
On (23/06/22 16:53), Qi Zheng wrote:
> +/*
> + * Remove one
> + */
> +void unregister_shrinker(struct shrinker *shrinker)
> +{
> + struct dentry *debugfs_entry;
> + int debugfs_id;
> +
> + if (!(shrinker->flags & SHRINKER_REGISTERED))
> + return;
> +
> + shrinker_put(shrinker);
> + wait_for_completion(>completion_wait);
> +
> + mutex_lock(_mutex);
> + list_del_rcu(>list);
Should this function wait for RCU grace period(s) before it goes
touching shrinker fields?
> + shrinker->flags &= ~SHRINKER_REGISTERED;
> + if (shrinker->flags & SHRINKER_MEMCG_AWARE)
> + unregister_memcg_shrinker(shrinker);
> + debugfs_entry = shrinker_debugfs_detach(shrinker, _id);
> + mutex_unlock(_mutex);
> +
> + shrinker_debugfs_remove(debugfs_entry, debugfs_id);
> +
> + kfree(shrinker->nr_deferred);
> + shrinker->nr_deferred = NULL;
> +}
> +EXPORT_SYMBOL(unregister_shrinker);
[..]
> +void shrinker_free(struct shrinker *shrinker)
> +{
> + kfree(shrinker);
> +}
> +EXPORT_SYMBOL(shrinker_free);
> +
> +void unregister_and_free_shrinker(struct shrinker *shrinker)
> +{
> + unregister_shrinker(shrinker);
> + kfree_rcu(shrinker, rcu);
> +}
Seems like this
unregister_shrinker();
shrinker_free();
is not exact equivalent of this
unregister_and_free_shrinker();
Re: [Intel-gfx] drm/i915: __GFP_RETRY_MAYFAIL allocations in stable kernels
On (21/06/17 19:27), Daniel Vetter wrote: > > > > So can all allocations in gen8_init_scratch() use > > GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN > > Yeah that looks all fairly broken tbh. The only thing I didn't know was > that GFP_DMA32 wasn't a full gfp mask with reclaim bits set as needed. I > guess it would be clearer if we use GFP_KERNEL | __GFP_DMA32 for these. Looks good. > The commit that introduced a lot of this, including I915_GFP_ALLOW_FAIL > seems to be > > commit 1abb70f5955d1a9021f96359a2c6502ca569b68d > Author: Chris Wilson > Date: Tue May 22 09:36:43 2018 +0100 > > drm/i915/gtt: Allow pagedirectory allocations to fail > > which used a selftest as justification, not real world workloads, so looks > rather dubious. Exactly, the commit we landed internally partially reverts 1abb70f5955 in 4.19 and 5.4 kernels. I don't mind I915_GFP_ALLOW_FAIL and so on, I kept those bits, but we need reclaim. I can reproduce cases when order:0 allocation fails with __GFP_HIGHMEM|__GFP_RETRY_MAYFAIL but succeeds with GFP_KERNEL|__GFP_HIGHMEM|__GFP_RETRY_MAYFAIL ON a side note, I'm not very sure if __GFP_RETRY_MAYFAIL is actually needed. Especially seeing it in syscalls is a bit uncommon: drm_ioctl() i915_gem_context_create_ioctl() i915_gem_create_context() i915_ppgtt_create() setup_scratch_page() // __GFP_RETRY_MAYFAIL But with GFP_KERNEL at least it tries to make some reclaim progress between retries, so it seems to be good enough. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm/i915: __GFP_RETRY_MAYFAIL allocations in stable kernels
Hi,
We are observing some user-space crashes (sigabort, segfaults etc.)
under moderate memory pressure (pretty far from severe pressure) which
have one thing in common - restrictive GFP mask in setup_scratch_page().
For instance, (stable 4.19) drivers/gpu/drm/i915/i915_gem_gtt.c
(trimmed down version)
static int gen8_init_scratch(struct i915_address_space *vm)
{
setup_scratch_page(vm, __GFP_HIGHMEM);
vm->scratch_pt = alloc_pt(vm);
vm->scratch_pd = alloc_pd(vm);
if (use_4lvl(vm)) {
vm->scratch_pdp = alloc_pdp(vm);
}
}
gen8_init_scratch() function puts a rather inconsistent restrictions on mm.
Looking at it line by line:
setup_scratch_page() uses very restrictive gfp mask:
__GFP_HIGHMEM | __GFP_ZERO | __GFP_RETRY_MAYFAIL
it doesn't try to reclaim anything and fails almost immediately.
alloc_pt() - uses more permissive gfp mask:
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN
alloc_pd() - likewise:
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN
alloc_pdp() - very permissive gfp mask:
GFP_KERNEL
So can all allocations in gen8_init_scratch() use
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN
?
E.g.
---
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index a12430187108..e862680b9c93 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -792,7 +792,7 @@ alloc_pdp(struct i915_address_space *vm)
GEM_BUG_ON(!use_4lvl(vm));
- pdp = kzalloc(sizeof(*pdp), GFP_KERNEL);
+ pdp = kzalloc(sizeof(*pdp), I915_GFP_ALLOW_FAIL);
if (!pdp)
return ERR_PTR(-ENOMEM);
@@ -1262,7 +1262,7 @@ static int gen8_init_scratch(struct i915_address_space
*vm)
{
int ret;
- ret = setup_scratch_page(vm, __GFP_HIGHMEM);
+ ret = setup_scratch_page(vm, GFP_KERNEL | __GFP_HIGHMEM);
if (ret)
return ret;
@@ -1972,7 +1972,7 @@ static int gen6_ppgtt_init_scratch(struct gen6_hw_ppgtt
*ppgtt)
u32 pde;
int ret;
- ret = setup_scratch_page(vm, __GFP_HIGHMEM);
+ ret = setup_scratch_page(vm, GFP_KERNEL | __GFP_HIGHMEM);
if (ret)
return ret;
@@ -3078,7 +3078,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64
size)
return -ENOMEM;
}
- ret = setup_scratch_page(>vm, GFP_DMA32);
+ ret = setup_scratch_page(>vm, GFP_KERNEL | GFP_DMA32);
if (ret) {
DRM_ERROR("Scratch setup failed\n");
/* iounmap will also get called at remove, but meh */
---
It's quite similar on stable 5.4 - setup_scratch_page() uses restrictive
gfp mask again.
---
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index f614646ed3f9..99d78b1052df 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1378,7 +1378,7 @@ static int gen8_init_scratch(struct i915_address_space
*vm)
return 0;
}
- ret = setup_scratch_page(vm, __GFP_HIGHMEM);
+ ret = setup_scratch_page(vm, GFP_KERNEL | __GFP_HIGHMEM);
if (ret)
return ret;
@@ -1753,7 +1753,7 @@ static int gen6_ppgtt_init_scratch(struct gen6_ppgtt
*ppgtt)
struct i915_page_directory * const pd = ppgtt->base.pd;
int ret;
- ret = setup_scratch_page(vm, __GFP_HIGHMEM);
+ ret = setup_scratch_page(vm, GFP_KERNEL | __GFP_HIGHMEM);
if (ret)
return ret;
@@ -2860,7 +2860,7 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64
size)
return -ENOMEM;
}
- ret = setup_scratch_page(>vm, GFP_DMA32);
+ ret = setup_scratch_page(>vm, GFP_KERNEL | GFP_DMA32);
if (ret) {
DRM_ERROR("Scratch setup failed\n");
/* iounmap will also get called at remove, but meh */
---
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv2 2/2] i915: do not leak module ref counter
Always put_filesystem() in i915_gemfs_init(). Signed-off-by: Sergey Senozhatsky --- - v2: rebased (i915 does not remount gemfs anymore) drivers/gpu/drm/i915/gem/i915_gemfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c b/drivers/gpu/drm/i915/gem/i915_gemfs.c index 5e6e8c91ab38..0a398e1e45fc 100644 --- a/drivers/gpu/drm/i915/gem/i915_gemfs.c +++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c @@ -30,6 +30,7 @@ int i915_gemfs_init(struct drm_i915_private *i915) */ gemfs = kern_mount(type); + put_filesystem(type); if (IS_ERR(gemfs)) return PTR_ERR(gemfs); -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv2 1/2] fs: export put_filesystem()
Modules, e.g. i915, can use exported get_fs_type(), but are
unable to put_filesystem(). Export it and let modules to
decrement file systems' reference counters.
Signed-off-by: Sergey Senozhatsky
---
fs/filesystems.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/filesystems.c b/fs/filesystems.c
index 9135646e41ac..02669839b584 100644
--- a/fs/filesystems.c
+++ b/fs/filesystems.c
@@ -45,6 +45,7 @@ void put_filesystem(struct file_system_type *fs)
{
module_put(fs->owner);
}
+EXPORT_SYMBOL(put_filesystem);
static struct file_system_type **find_filesystem(const char *name, unsigned
len)
{
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Stop reconfiguring our shmemfs mountpoint
On (08/08/19 18:22), Chris Wilson wrote: [..] > @@ -20,31 +20,18 @@ int i915_gemfs_init(struct drm_i915_private *i915) > if (!type) > return -ENODEV; [..] > + gemfs = kern_mount(type); > + if (IS_ERR(gemfs)) > + return PTR_ERR(gemfs); > > i915->mm.gemfs = gemfs; We still have to put_filesystem(). Right? -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [linux-next] mm/i915: i915_gemfs_init() NULL dereference
On (08/01/19 18:30), Chris Wilson wrote:
> Quoting Sergey Senozhatsky (2019-07-31 17:48:29)
> > @@ -36,19 +38,35 @@ int i915_gemfs_init(struct drm_i915_private *i915)
[..]
> > + if (!fc->ops->parse_monolithic)
> > + goto err;
> > +
> > + err = fc->ops->parse_monolithic(fc, options);
> > + if (err)
> > + goto err;
> > +
> > + if (!fc->ops->reconfigure)
>
> It would be odd for fs_context_for_reconfigure() to allow creation of a
> context if that context couldn't perform a reconfigre, nevertheless that
> seems to be the case.
Well, I kept those checks just because fs/ code does the same.
E.g. fs/super.c
reconfigure_super()
{
if (fc->ops->reconfigure)
fc->ops->reconfigure(fc)
}
do_emergency_remount_callback()
{
fc = fs_context_for_reconfigure();
reconfigure_super(fc);
}
> > + goto err;
> > +
> > + err = fc->ops->reconfigure(fc);
> > + if (err)
> > + goto err;
>
> Only thing that stands out is that we should put_fs_context() here as
> well.
Oh... Indeed, somehow I forgot to put_fs_context().
> I guess it's better than poking at the SB_INFO directly ourselves.
> I think though we shouldn't bail if we can't change the thp setting, and
> just accept whatever with a warning.
OK.
> Looks like the API is already available in dinq, so we can apply this
> ahead of the next merge window.
OK, will cook a formal patch then. Thanks!
-ss
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCHv2 2/3] i915: convert to new mount API
On (08/05/19 19:12), Al Viro wrote: [..] > On Tue, Aug 06, 2019 at 01:03:06AM +0900, Sergey Senozhatsky wrote: > > tmpfs does not set ->remount_fs() anymore and its users need > > to be converted to new mount API. > > Could you explain why the devil do you bother with remount at all? I would redirect this question to i915 developers. As far as I know i915 performance suffers with huge pages enabled. > Why not pass the right options when mounting the damn thing? vfs_kern_mount()? It still requires struct file_system_type, which we need to get and put. -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv2 3/3] i915: do not leak module ref counter
put_filesystem() must follow get_fs_type(). Signed-off-by: Sergey Senozhatsky --- drivers/gpu/drm/i915/gem/i915_gemfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c b/drivers/gpu/drm/i915/gem/i915_gemfs.c index feedc9242072..93ac365ce9ce 100644 --- a/drivers/gpu/drm/i915/gem/i915_gemfs.c +++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c @@ -24,6 +24,7 @@ int i915_gemfs_init(struct drm_i915_private *i915) return -ENODEV; gemfs = kern_mount(type); + put_filesystem(type); if (IS_ERR(gemfs)) return PTR_ERR(gemfs); -- 2.22.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv2 2/3] i915: convert to new mount API
tmpfs does not set ->remount_fs() anymore and its users need
to be converted to new mount API.
BUG: kernel NULL pointer dereference, address:
PF: supervisor instruction fetch in kernel mode
PF: error_code(0x0010) - not-present page
RIP: 0010:0x0
Code: Bad RIP value.
Call Trace:
i915_gemfs_init+0x6e/0xa0 [i915]
i915_gem_init_early+0x76/0x90 [i915]
i915_driver_probe+0x30a/0x1640 [i915]
? kernfs_activate+0x5a/0x80
? kernfs_add_one+0xdd/0x130
pci_device_probe+0x9e/0x110
really_probe+0xce/0x230
driver_probe_device+0x4b/0xc0
device_driver_attach+0x4e/0x60
__driver_attach+0x47/0xb0
? device_driver_attach+0x60/0x60
bus_for_each_dev+0x61/0x90
bus_add_driver+0x167/0x1b0
driver_register+0x67/0xaa
Signed-off-by: Sergey Senozhatsky
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gemfs.c | 32 +++
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c
b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index 099f3397aada..feedc9242072 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -7,14 +7,17 @@
#include
#include
#include
+#include
#include "i915_drv.h"
#include "i915_gemfs.h"
int i915_gemfs_init(struct drm_i915_private *i915)
{
+ struct fs_context *fc = NULL;
struct file_system_type *type;
struct vfsmount *gemfs;
+ bool ok = true;
type = get_fs_type("tmpfs");
if (!type)
@@ -36,18 +39,29 @@ int i915_gemfs_init(struct drm_i915_private *i915)
struct super_block *sb = gemfs->mnt_sb;
/* FIXME: Disabled until we get W/A for read BW issue. */
char options[] = "huge=never";
- int flags = 0;
- int err;
-
- err = sb->s_op->remount_fs(sb, , options);
- if (err) {
- kern_unmount(gemfs);
- return err;
- }
+
+ ok = false;
+ fc = fs_context_for_reconfigure(sb->s_root, 0, 0);
+ if (IS_ERR(fc))
+ goto out;
+
+ if (!fc->ops->parse_monolithic ||
+ fc->ops->parse_monolithic(fc, options))
+ goto out;
+
+ if (fc->ops->reconfigure && !fc->ops->reconfigure(fc))
+ ok = true;
}
+out:
+ if (!ok)
+ dev_err(i915->drm.dev,
+ "Unable to reconfigure %s. %s\n",
+ "shmemfs for preferred allocation strategy",
+ "Continuing, but performance may suffer");
+ if (!IS_ERR_OR_NULL(fc))
+ put_fs_context(fc);
i915->mm.gemfs = gemfs;
-
return 0;
}
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv2 1/3] fs: export put_filesystem()
Modules can use get_fs_type(), which is exported, but are unable
to put_filesystem(). Export it and let modules to also decrement
corresponding file systems' reference counters.
Signed-off-by: Sergey Senozhatsky
---
fs/filesystems.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/filesystems.c b/fs/filesystems.c
index 9135646e41ac..02669839b584 100644
--- a/fs/filesystems.c
+++ b/fs/filesystems.c
@@ -45,6 +45,7 @@ void put_filesystem(struct file_system_type *fs)
{
module_put(fs->owner);
}
+EXPORT_SYMBOL(put_filesystem);
static struct file_system_type **find_filesystem(const char *name, unsigned
len)
{
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCHv2 0/3] convert i915 to new mount API
Hello, Convert i915 to a new mount API and fix i915_gemfs_init() kernel Oops. It also appears that we need to EXPORTs put_filesystem(), so i915 can properly put filesystem after it is done with kern_mount(). v2: - export put_filesystem() [Chris] - always put_filesystem() in i915_gemfs_init() [Chris] - improve i915_gemfs_init() error message [Chris] Sergey Senozhatsky (3): fs: export put_filesystem() i915: convert to new mount API i915: do not leak module ref counter drivers/gpu/drm/i915/gem/i915_gemfs.c | 33 +++ fs/filesystems.c | 1 + 2 files changed, 25 insertions(+), 9 deletions(-) -- 2.22.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] i915: do not leak module ref counter
On (08/02/19 14:41), Chris Wilson wrote:
[..]
> struct vfsmount *kern_mount(struct file_system_type *type)
> {
> struct vfsmount *mnt;
> mnt = vfs_kern_mount(type, SB_KERNMOUNT, type->name, NULL);
> if (!IS_ERR(mnt)) {
> /*
> * it is a longterm mount, don't release mnt until
> * we unmount before file sys is unregistered
> */
> real_mount(mnt)->mnt_ns = MNT_NS_INTERNAL;
> }
> return mnt;
> }
>
> With the exception of fiddling with MNT_NS_INTERNAL, it seems
> amenable for our needs.
Sorry, not sure I understand. i915 use kern_mount() at the moment.
Since we still need to put_filesystem(), I'd probably add one more
patch
- export put_filesystem()
so then we can put_filesystem() in i915. Wonder what would happen
if someone would do
modprobe i915
rmmod i916
In a loop.
So something like this (this is against current patch set).
---
drivers/gpu/drm/i915/gem/i915_gemfs.c | 5 ++---
fs/filesystems.c | 2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c
b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index d437188d1736..4ea7a6f750f4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -24,10 +24,9 @@ int i915_gemfs_init(struct drm_i915_private *i915)
return -ENODEV;
gemfs = kern_mount(type);
- if (IS_ERR(gemfs)) {
- put_filesystem(type);
+ put_filesystem(type);
+ if (IS_ERR(gemfs))
return PTR_ERR(gemfs);
- }
/*
* Enable huge-pages for objects that are at least HPAGE_PMD_SIZE, most
diff --git a/fs/filesystems.c b/fs/filesystems.c
index 9135646e41ac..4837eda748b5 100644
--- a/fs/filesystems.c
+++ b/fs/filesystems.c
@@ -45,6 +45,7 @@ void put_filesystem(struct file_system_type *fs)
{
module_put(fs->owner);
}
+EXPORT_SYMBOL(put_filesystem);
static struct file_system_type **find_filesystem(const char *name, unsigned
len)
{
@@ -280,5 +281,4 @@ struct file_system_type *get_fs_type(const char *name)
}
return fs;
}
-
EXPORT_SYMBOL(get_fs_type);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] i915: do not leak module ref counter
On (08/02/19 22:15), Sergey Senozhatsky wrote:
[..]
> > > Looking around, it looks like we always need to drop type after
> > > mounting. Should the
> > > put_filesystem(type);
> > > be here instead?
> > >
> > > Anyway, nice catch.
> >
> > Sigh. put_filesystem() is part of fs internals. I'd be tempted to add
>
> Good catch!
>
> So we can switch to vfs_kern_mount(), I guess, but pass different options,
> depending on has_transparent_hugepage().
Hmm. This doesn't look exactly right. It appears that vfs_kern_mount()
has a slightly different purpose. It's for drivers which register their
own fstype and fs_context/sb callbacks. A typical usage would be
static struct file_system_type nfsd_fs_type = {
.owner→ → = THIS_MODULE,
.name→ → = "nfsd",
.init_fs_context = nfsd_init_fs_context,
.kill_sb→ = nfsd_umount,
};
MODULE_ALIAS_FS("nfsd");
vfs_kern_mount(_fs_type, SB_KERNMOUNT, "nfsd", NULL);
i915 is a different beast, it just wants to mount fs and reconfigure
it, it doesn't want to be an fs. So it seems that current kern_mount()
is actually right.
Maybe we need to export put_filesystem() instead.
-ss
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] i915: do not leak module ref counter
On (08/02/19 14:10), Chris Wilson wrote: > > > drivers/gpu/drm/i915/gem/i915_gemfs.c | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c > > > b/drivers/gpu/drm/i915/gem/i915_gemfs.c > > > index cf05ba72df9d..d437188d1736 100644 > > > --- a/drivers/gpu/drm/i915/gem/i915_gemfs.c > > > +++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c > > > @@ -24,8 +24,10 @@ int i915_gemfs_init(struct drm_i915_private *i915) > > > return -ENODEV; > > > > > > gemfs = kern_mount(type); > > > > Looking around, it looks like we always need to drop type after > > mounting. Should the > > put_filesystem(type); > > be here instead? > > > > Anyway, nice catch. > > Sigh. put_filesystem() is part of fs internals. I'd be tempted to add Good catch! So we can switch to vfs_kern_mount(), I guess, but pass different options, depending on has_transparent_hugepage(). -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] i915: convert to new mount API
On (08/02/19 13:54), Chris Wilson wrote:
[..]
> > int i915_gemfs_init(struct drm_i915_private *i915)
> > {
> > + struct fs_context *fc = NULL;
> > struct file_system_type *type;
> > struct vfsmount *gemfs;
> > + bool ok = true;
>
> Start with ok = false, we only need to set to true if we succeed in
> reconfiguring.
OK, makes sense.
> > type = get_fs_type("tmpfs");
> > if (!type)
> > @@ -36,18 +39,29 @@ int i915_gemfs_init(struct drm_i915_private *i915)
> > struct super_block *sb = gemfs->mnt_sb;
> > /* FIXME: Disabled until we get W/A for read BW issue. */
> > char options[] = "huge=never";
> > - int flags = 0;
> > - int err;
>
> Hmm, we could avoid this if we used vfs_kernel_mount() directly rather
> than the kern_mount wrapper, as then we pass options through to
> parse_monotithic_mount_data(). Or am I barking up the wrong tree?
Hmm.
Wouldn't this error on !TRANSPARENT_HUGE_PAGECACHE systems?
"huge=never" should be an invalid option when system does
not know about THP.
[..]
> > + if (!fc->ops->parse_monolithic ||
> > + fc->ops->parse_monolithic(fc, options)) {
>
> checkpatch.pl will complain that this should line up with the '('
It doesn't.
-
outgoing/0001-i915-convert-to-new-mount-API.patch
-
total: 0 errors, 0 warnings, 53 lines checked
outgoing/0001-i915-convert-to-new-mount-API.patch has no obvious style problems
and is ready for submission.
---
outgoing/0002-i915-do-not-leak-module-ref-counter.patch
---
total: 0 errors, 0 warnings, 11 lines checked
outgoing/0002-i915-do-not-leak-module-ref-counter.patch has no obvious style
problems and is ready for submission.
[..]
> > + if (!ok)
> > + pr_err("i915 gemfs reconfiguration failed\n");
>
> Let's make it a bit more user friendly,
>
> dev_err(i915->drm.dev,
> "Unable to reconfigure internal shmemfs for preferred"
> " allocation strategy; continuing, but performance may suffer.\n");
I guess now checkpatch will complain :)
> Assuming that we can't just use vfs_kern_mount() instead, with the nits
> Reviewed-by: Chris Wilson
Thanks.
I'll sit on it for several days, just to see if more feedback will come.
-ss
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] i915: do not leak module ref counter
put_filesystem() before i915_gemfs_init() deals with
kern_mount() error.
Signed-off-by: Sergey Senozhatsky
---
drivers/gpu/drm/i915/gem/i915_gemfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c
b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index cf05ba72df9d..d437188d1736 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -24,8 +24,10 @@ int i915_gemfs_init(struct drm_i915_private *i915)
return -ENODEV;
gemfs = kern_mount(type);
- if (IS_ERR(gemfs))
+ if (IS_ERR(gemfs)) {
+ put_filesystem(type);
return PTR_ERR(gemfs);
+ }
/*
* Enable huge-pages for objects that are at least HPAGE_PMD_SIZE, most
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] i915: convert to new mount API
tmpfs does not set ->remount_fs() anymore and its users need
to be converted to new mount API.
BUG: kernel NULL pointer dereference, address:
PF: supervisor instruction fetch in kernel mode
PF: error_code(0x0010) - not-present page
RIP: 0010:0x0
Code: Bad RIP value.
Call Trace:
i915_gemfs_init+0x6e/0xa0 [i915]
i915_gem_init_early+0x76/0x90 [i915]
i915_driver_probe+0x30a/0x1640 [i915]
? kernfs_activate+0x5a/0x80
? kernfs_add_one+0xdd/0x130
pci_device_probe+0x9e/0x110
really_probe+0xce/0x230
driver_probe_device+0x4b/0xc0
device_driver_attach+0x4e/0x60
__driver_attach+0x47/0xb0
? device_driver_attach+0x60/0x60
bus_for_each_dev+0x61/0x90
bus_add_driver+0x167/0x1b0
driver_register+0x67/0xaa
Signed-off-by: Sergey Senozhatsky
---
drivers/gpu/drm/i915/gem/i915_gemfs.c | 28 ---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c
b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index 099f3397aada..cf05ba72df9d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -7,14 +7,17 @@
#include
#include
#include
+#include
#include "i915_drv.h"
#include "i915_gemfs.h"
int i915_gemfs_init(struct drm_i915_private *i915)
{
+ struct fs_context *fc = NULL;
struct file_system_type *type;
struct vfsmount *gemfs;
+ bool ok = true;
type = get_fs_type("tmpfs");
if (!type)
@@ -36,18 +39,29 @@ int i915_gemfs_init(struct drm_i915_private *i915)
struct super_block *sb = gemfs->mnt_sb;
/* FIXME: Disabled until we get W/A for read BW issue. */
char options[] = "huge=never";
- int flags = 0;
- int err;
- err = sb->s_op->remount_fs(sb, , options);
- if (err) {
- kern_unmount(gemfs);
- return err;
+ fc = fs_context_for_reconfigure(sb->s_root, 0, 0);
+ if (IS_ERR(fc)) {
+ ok = false;
+ goto out;
}
+
+ if (!fc->ops->parse_monolithic ||
+ fc->ops->parse_monolithic(fc, options)) {
+ ok = false;
+ goto out;
+ }
+
+ if (!fc->ops->reconfigure || fc->ops->reconfigure(fc))
+ ok = false;
}
+out:
+ if (!ok)
+ pr_err("i915 gemfs reconfiguration failed\n");
+ if (!IS_ERR_OR_NULL(fc))
+ put_fs_context(fc);
i915->mm.gemfs = gemfs;
-
return 0;
}
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [linux-next] mm/i915: i915_gemfs_init() NULL dereference
On (07/21/19 23:29), Sergey Senozhatsky wrote:
>
> BUG: kernel NULL pointer dereference, address:
> #PF: supervisor instruction fetch in kernel mode
> #PF: error_code(0x0010) - not-present page
> PGD 0 P4D 0
> Oops: 0010 [#1] PREEMPT SMP PTI
> RIP: 0010:0x0
> Code: Bad RIP value.
> [..]
> Call Trace:
> i915_gemfs_init+0x6e/0xa0 [i915]
> i915_gem_init_early+0x76/0x90 [i915]
> i915_driver_probe+0x30a/0x1640 [i915]
> ? kernfs_activate+0x5a/0x80
> ? kernfs_add_one+0xdd/0x130
> pci_device_probe+0x9e/0x110
> really_probe+0xce/0x230
> driver_probe_device+0x4b/0xc0
> device_driver_attach+0x4e/0x60
> __driver_attach+0x47/0xb0
> ? device_driver_attach+0x60/0x60
> bus_for_each_dev+0x61/0x90
> bus_add_driver+0x167/0x1b0
> driver_register+0x67/0xaa
> ? 0xc0522000
> do_one_initcall+0x37/0x13f
> ? kmem_cache_alloc+0x11a/0x150
> do_init_module+0x51/0x200
> __se_sys_init_module+0xef/0x100
> do_syscall_64+0x49/0x250
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
So "the new mount API" conversion probably looks like something below.
But I'm not 100% sure.
---
drivers/gpu/drm/i915/gem/i915_gemfs.c | 32 +--
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c
b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index 099f3397aada..2e365b26f8ee 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -7,12 +7,14 @@
#include
#include
#include
+#include
#include "i915_drv.h"
#include "i915_gemfs.h"
int i915_gemfs_init(struct drm_i915_private *i915)
{
+ struct fs_context *fc;
struct file_system_type *type;
struct vfsmount *gemfs;
@@ -36,19 +38,35 @@ int i915_gemfs_init(struct drm_i915_private *i915)
struct super_block *sb = gemfs->mnt_sb;
/* FIXME: Disabled until we get W/A for read BW issue. */
char options[] = "huge=never";
- int flags = 0;
int err;
- err = sb->s_op->remount_fs(sb, , options);
- if (err) {
- kern_unmount(gemfs);
- return err;
- }
+ fc = fs_context_for_reconfigure(sb->s_root, 0, 0);
+ if (IS_ERR(fc))
+ goto err;
+
+ if (!fc->ops->parse_monolithic)
+ goto err;
+
+ err = fc->ops->parse_monolithic(fc, options);
+ if (err)
+ goto err;
+
+ if (!fc->ops->reconfigure)
+ goto err;
+
+ err = fc->ops->reconfigure(fc);
+ if (err)
+ goto err;
}
i915->mm.gemfs = gemfs;
-
return 0;
+
+err:
+ pr_err("i915 gemfs init() failed\n");
+ put_fs_context(fc);
+ kern_unmount(gemfs);
+ return -EINVAL;
}
void i915_gemfs_fini(struct drm_i915_private *i915)
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [linux-next] mm/i915: i915_gemfs_init() NULL dereference
Hi,
My laptop oopses early on with nothing on the screen;
after some debugging I managed to obtain a backtrace:
BUG: kernel NULL pointer dereference, address:
#PF: supervisor instruction fetch in kernel mode
#PF: error_code(0x0010) - not-present page
PGD 0 P4D 0
Oops: 0010 [#1] PREEMPT SMP PTI
RIP: 0010:0x0
Code: Bad RIP value.
[..]
Call Trace:
i915_gemfs_init+0x6e/0xa0 [i915]
i915_gem_init_early+0x76/0x90 [i915]
i915_driver_probe+0x30a/0x1640 [i915]
? kernfs_activate+0x5a/0x80
? kernfs_add_one+0xdd/0x130
pci_device_probe+0x9e/0x110
really_probe+0xce/0x230
driver_probe_device+0x4b/0xc0
device_driver_attach+0x4e/0x60
__driver_attach+0x47/0xb0
? device_driver_attach+0x60/0x60
bus_for_each_dev+0x61/0x90
bus_add_driver+0x167/0x1b0
driver_register+0x67/0xaa
? 0xc0522000
do_one_initcall+0x37/0x13f
? kmem_cache_alloc+0x11a/0x150
do_init_module+0x51/0x200
__se_sys_init_module+0xef/0x100
do_syscall_64+0x49/0x250
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP is at 0x00, which is never good
It sort of boils down to commit 144df3b288c4 (vfs: Convert ramfs,
shmem, tmpfs, devtmpfs, rootfs to use the new mount API), which
removed ->remount_fs from tmpfs' ops:
===
@@ -3736,7 +3849,6 @@ static const struct super_operations shmem_ops = {
.destroy_inode = shmem_destroy_inode,
#ifdef CONFIG_TMPFS
.statfs = shmem_statfs,
- .remount_fs = shmem_remount_fs,
.show_options = shmem_show_options,
#endif
.evict_inode= shmem_evict_inode,
===
So i915 init executes NULL
get_fs_type("tmpfs");
sb->s_op->remount_fs(sb, , options);
For the time being the following (obvious and wrong) patch
at least boots -next:
---
diff --git a/drivers/gpu/drm/i915/gem/i915_gemfs.c
b/drivers/gpu/drm/i915/gem/i915_gemfs.c
index 099f3397aada..1f95d9ea319a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gemfs.c
+++ b/drivers/gpu/drm/i915/gem/i915_gemfs.c
@@ -39,6 +39,9 @@ int i915_gemfs_init(struct drm_i915_private *i915)
int flags = 0;
int err;
+ if (!sb->s_op->remount_fs)
+ return -ENODEV;
+
err = sb->s_op->remount_fs(sb, , options);
if (err) {
kern_unmount(gemfs);
---
-ss
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] lib/hexdump.c: Allow multiple groups to be separated by lines '|'
On (04/10/19 13:17), Alastair D'Silva wrote: > With the wider display format, it can become hard to identify how many > bytes into the line you are looking at. > > The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to > print vertical lines to separate every N groups of bytes. > > eg. > buf:: 454d414e 43415053|4e495f45 00584544 NAMESPAC|E_INDEX. > buf:0010: 0002| | What if the output had |-s in it? | -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [linux-next-20170523] possible circular locking dependency detected
Hello,
[9.610781] ==
[9.610784] WARNING: possible circular locking dependency detected
[9.610789] 4.12.0-rc2-next-20170523-dbg-dirty #231 Not tainted
[9.610791] --
[9.610795] Xorg/341 is trying to acquire lock:
[9.610798] (cpu_hotplug_lock.rw_sem){++}, at: []
apply_wqattrs_lock+0x9/0x19
[9.610816]
but task is already holding lock:
[9.610818] (_priv->mm_lock){+.+.+.}, at: []
i915_gem_userptr_init__mmu_notifier+0x85/0x213
[9.610834]
which lock already depends on the new lock.
[9.610837]
the existing dependency chain (in reverse order) is:
[9.610839]
-> #5 (_priv->mm_lock){+.+.+.}:
[9.610854]lock_acquire+0x46/0x60
[9.610861]__mutex_lock+0x90/0x7b5
[9.610867]mutex_lock_nested+0x16/0x18
[9.610872]i915_gem_userptr_init__mmu_notifier+0x85/0x213
[9.610878]i915_gem_userptr_ioctl+0x1cd/0x2b6
[9.610884]drm_ioctl+0x258/0x373
[9.610893]vfs_ioctl+0x13/0x2f
[9.610899]do_vfs_ioctl+0x5eb/0x5fe
[9.610905]SyS_ioctl+0x3e/0x5c
[9.610913]entry_SYSCALL_64_fastpath+0x18/0xad
[9.610915]
-> #4 (>mmap_sem){++}:
[9.610926]lock_acquire+0x46/0x60
[9.610933]__might_fault+0x5c/0x7f
[9.610939]filldir+0xb3/0x125
[9.610947]call_filldir+0xb9/0xde
[9.610952]ext4_readdir+0x1ff/0x676
[9.610958]iterate_dir+0x93/0x13d
[9.610964]SyS_getdents+0xa4/0x117
[9.610971]entry_SYSCALL_64_fastpath+0x18/0xad
[9.610973]
-> #3 (>i_mutex_dir_key#2){++}:
[9.610986]lock_acquire+0x46/0x60
[9.610992]down_read+0x39/0x5d
[9.610997]lookup_slow+0x7c/0x17f
[9.611002]walk_component+0xcd/0x214
[9.611007]link_path_walk+0xfa/0x44a
[9.611013]path_openat+0x213/0x6f9
[9.611018]do_filp_open+0x48/0x9e
[9.611024]file_open_name+0xe7/0xe9
[9.611028]filp_open+0x2d/0x44
[9.611032]kernel_read_file_from_path+0x33/0x6c
[9.611039]_request_firmware+0x39d/0x629
[9.611044]request_firmware_work_func+0x23/0x55
[9.611049]process_one_work+0x1c3/0x323
[9.611055]worker_thread+0x1ee/0x2c0
[9.611060]kthread+0x127/0x12f
[9.611064]ret_from_fork+0x2e/0x40
[9.611066]
-> #2 (umhelper_sem){.+}:
[9.611077]lock_acquire+0x46/0x60
[9.611083]down_read+0x39/0x5d
[9.611088]usermodehelper_read_trylock+0x51/0x100
[9.611092]_request_firmware+0x2dc/0x629
[9.611097]request_firmware_direct+0x36/0x48
[9.611103]request_microcode_fw+0x54/0x88
[9.611107]reload_store+0xaa/0x114
[9.64]dev_attr_store+0x14/0x1e
[9.611121]sysfs_kf_write+0x44/0x4b
[9.611127]kernfs_fop_write+0x117/0x161
[9.611132]__vfs_write+0x21/0xe7
[9.611137]vfs_write+0xdc/0x165
[9.611142]SyS_write+0x4c/0x89
[9.611149]entry_SYSCALL_64_fastpath+0x18/0xad
[9.611151]
-> #1 (microcode_mutex){+.+.+.}:
[9.611162]lock_acquire+0x46/0x60
[9.611167]__mutex_lock+0x90/0x7b5
[9.611173]mutex_lock_nested+0x16/0x18
[9.611181]microcode_init+0xb8/0x1d7
[9.611187]do_one_initcall+0x8b/0x121
[9.611192]kernel_init_freeable+0x139/0x1c2
[9.611197]kernel_init+0x9/0xe6
[9.611201]ret_from_fork+0x2e/0x40
[9.611203]
-> #0 (cpu_hotplug_lock.rw_sem){++}:
[9.611214]__lock_acquire+0xec4/0x1444
[9.611219]lock_acquire+0x46/0x60
[9.611226]get_online_cpus+0x38/0x98
[9.611231]apply_wqattrs_lock+0x9/0x19
[9.611237]apply_workqueue_attrs+0x15/0x2f
[9.611244]__alloc_workqueue_key+0x2b2/0x457
[9.611250]i915_gem_userptr_init__mmu_notifier+0xfb/0x213
[9.611255]i915_gem_userptr_ioctl+0x1cd/0x2b6
[9.611260]drm_ioctl+0x258/0x373
[9.611266]vfs_ioctl+0x13/0x2f
[9.611272]do_vfs_ioctl+0x5eb/0x5fe
[9.611278]SyS_ioctl+0x3e/0x5c
[9.611284]entry_SYSCALL_64_fastpath+0x18/0xad
[9.611287]
other info that might help us debug this:
[9.611290] Chain exists of:
cpu_hotplug_lock.rw_sem --> >mmap_sem -->
_priv->mm_lock
[9.611301] Possible unsafe locking scenario:
[9.611304]CPU0CPU1
[9.611306]
[9.611308] lock(_priv->mm_lock);
[9.611314]lock(>mmap_sem);
[9.611319]
[Intel-gfx] [linux-mmotm] i915_gem_userptr_get_pages: possible circular locking dependency detected
Hello,
[ 530.698622] ==
[ 530.698623] WARNING: possible circular locking dependency detected
[ 530.698626] 4.11.0-rc2-mm1-dbg-00167-gdb8a9941614c-dirty #222 Not tainted
[ 530.698627] --
[ 530.698628] Xorg/343 is trying to acquire lock:
[ 530.698630] (>mmap_sem){++}, at: []
i915_gem_userptr_get_pages+0x60/0x29c [i915]
[ 530.698702]
but task is already holding lock:
[ 530.698703] (>mm.lock){+.+.+.}, at: []
__i915_gem_object_get_pages+0x21/0x62 [i915]
[ 530.698763]
which lock already depends on the new lock.
[ 530.698764]
the existing dependency chain (in reverse order) is:
[ 530.698766]
-> #1 (>mm.lock){+.+.+.}:
[ 530.698779]lock_acquire+0x130/0x1c4
[ 530.698822]i915_gem_fault+0x138/0x531 [i915]
[ 530.698826]__do_fault+0x1e/0xb4
[ 530.698831]__handle_mm_fault+0x897/0xe37
[ 530.698834]handle_mm_fault+0x93/0xd2
[ 530.698839]__do_page_fault+0x20c/0x3db
[ 530.698843]do_page_fault+0xc/0xe
[ 530.698848]page_fault+0x22/0x30
[ 530.698849]
-> #0 (>mmap_sem){++}:
[ 530.698858]__lock_acquire+0xf49/0x1548
[ 530.698861]lock_acquire+0x130/0x1c4
[ 530.698866]down_read+0x3e/0x62
[ 530.698910]i915_gem_userptr_get_pages+0x60/0x29c [i915]
[ 530.698951]i915_gem_object_get_pages+0x3f/0x57 [i915]
[ 530.698993]__i915_gem_object_get_pages+0x41/0x62 [i915]
[ 530.699035]i915_gem_set_domain_ioctl+0x1f6/0x2b0 [i915]
[ 530.699057]drm_ioctl+0x248/0x363 [drm]
[ 530.699061]vfs_ioctl+0x18/0x34
[ 530.699064]do_vfs_ioctl+0x5a2/0x64d
[ 530.699067]SyS_ioctl+0x43/0x61
[ 530.699070]entry_SYSCALL_64_fastpath+0x18/0xad
[ 530.699072]
other info that might help us debug this:
[ 530.699073] Possible unsafe locking scenario:
[ 530.699075]CPU0CPU1
[ 530.699076]
[ 530.699077] lock(>mm.lock);
[ 530.699081]lock(>mmap_sem);
[ 530.699084]lock(>mm.lock);
[ 530.699087] lock(>mmap_sem);
[ 530.699090]
*** DEADLOCK ***
[ 530.699092] 1 lock held by Xorg/343:
[ 530.699094] #0: (>mm.lock){+.+.+.}, at: []
__i915_gem_object_get_pages+0x21/0x62 [i915]
[ 530.699141]
stack backtrace:
[ 530.699144] CPU: 6 PID: 343 Comm: Xorg Not tainted
4.11.0-rc2-mm1-dbg-00167-gdb8a9941614c-dirty #222
[ 530.699146] Call Trace:
[ 530.699152] dump_stack+0x68/0x92
[ 530.699158] print_circular_bug+0x286/0x294
[ 530.699163] __lock_acquire+0xf49/0x1548
[ 530.699168] ? lock_acquire+0x130/0x1c4
[ 530.699173] lock_acquire+0x130/0x1c4
[ 530.699177] ? lock_acquire+0x130/0x1c4
[ 530.699223] ? i915_gem_userptr_get_pages+0x60/0x29c [i915]
[ 530.699228] down_read+0x3e/0x62
[ 530.699273] ? i915_gem_userptr_get_pages+0x60/0x29c [i915]
[ 530.699318] i915_gem_userptr_get_pages+0x60/0x29c [i915]
[ 530.699361] i915_gem_object_get_pages+0x3f/0x57 [i915]
[ 530.699403] __i915_gem_object_get_pages+0x41/0x62 [i915]
[ 530.699446] i915_gem_set_domain_ioctl+0x1f6/0x2b0 [i915]
[ 530.699463] drm_ioctl+0x248/0x363 [drm]
[ 530.699506] ? i915_gem_obj_prepare_shmem_write+0x1ba/0x1ba [i915]
[ 530.699511] vfs_ioctl+0x18/0x34
[ 530.699514] do_vfs_ioctl+0x5a2/0x64d
[ 530.699517] ? __fget+0x182/0x194
[ 530.699521] SyS_ioctl+0x43/0x61
[ 530.699524] entry_SYSCALL_64_fastpath+0x18/0xad
[ 530.699527] RIP: 0033:0x7fa1bb3150d7
[ 530.699529] RSP: 002b:7ffe1f1fbc48 EFLAGS: 0246 ORIG_RAX:
0010
[ 530.699534] RAX: ffda RBX: e000 RCX: 7fa1bb3150d7
[ 530.699536] RDX: 7ffe1f1fbc70 RSI: 400c645f RDI: 000b
[ 530.699538] RBP: a1fcd537 R08: 00ff R09: 01c564d8
[ 530.699540] R10: R11: 0246 R12: 0015
[ 530.699542] R13: 01c474b0 R14: 01f2 R15: 01c43488
-ss
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] RPM wakelock ref not held during HW access
Hello, -mmots 4.4.0-mm1-dbg-00602-g776bd09 [ 5331.509087] WARNING: CPU: 0 PID: 359 at drivers/gpu/drm/i915/intel_drv.h:1446 gen6_read32+0x7b/0x253 [i915]() [ 5331.509091] RPM wakelock ref not held during HW access [ 5331.509093] Modules linked in: [ 5331.509182] CPU: 0 PID: 359 Comm: Xorg Not tainted 4.4.0-mm1-dbg-00602-g776bd09-dirty #34 [ 5331.509186] 88041bddfac0 811eb860 88041bddfb08 [ 5331.509194] 88041bddfaf8 81040fc2 a05442a9 88041aab [ 5331.509200] 00064000 88041afcb001 0001 88041bddfb60 [ 5331.509207] Call Trace: [ 5331.509218] [] dump_stack+0x4b/0x63 [ 5331.509227] [] warn_slowpath_common+0x99/0xb2 [ 5331.509277] [] ? gen6_read32+0x7b/0x253 [i915] [ 5331.509283] [] warn_slowpath_fmt+0x48/0x50 [ 5331.509331] [] gen6_read32+0x7b/0x253 [i915] [ 5331.509338] [] ? mutex_unlock+0xe/0x10 [ 5331.509391] [] intel_ddi_get_hw_state+0x5e/0x159 [i915] [ 5331.509443] [] intel_ddi_connector_get_hw_state+0x5c/0xdf [i915] [ 5331.509494] [] intel_atomic_commit+0x8e0/0x1250 [i915] [ 5331.509528] [] ? drm_atomic_check_only+0x293/0x564 [drm] [ 5331.509558] [] drm_atomic_commit+0x4d/0x52 [drm] [ 5331.509572] [] drm_atomic_helper_connector_dpms+0x116/0x17e [drm_kms_helper] [ 5331.509599] [] drm_mode_obj_set_property_ioctl+0xef/0x17a [drm] [ 5331.509626] [] drm_mode_connector_property_set_ioctl+0x30/0x32 [drm] [ 5331.509642] [] drm_ioctl+0x26d/0x3a8 [drm] [ 5331.509668] [] ? drm_mode_obj_set_property_ioctl+0x17a/0x17a [drm] [ 5331.509675] [] ? lock_acquire+0x101/0x188 [ 5331.509681] [] ? __fget+0x5/0x19d [ 5331.509685] [] ? __lock_is_held+0x3c/0x57 [ 5331.509691] [] vfs_ioctl+0x18/0x34 [ 5331.509695] [] do_vfs_ioctl+0x572/0x5f1 [ 5331.509699] [] ? __fget_light+0x62/0x71 [ 5331.509704] [] SyS_ioctl+0x43/0x61 [ 5331.509711] [] entry_SYSCALL_64_fastpath+0x12/0x6f [ 5331.509715] ---[ end trace 70d4fd86a0395d92 ]--- -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
On (07/14/15 17:11), Daniel Vetter wrote: Have you forwarded to a more recent -nightly? I just merged a patch which might have fixed this ... Hello, yep, I use the most recent -next usually (update it everyday), when it boots. I can't reproduce the problem so far, hopefully the commit you mentioned above does fix it. I'll keep any eye and report back if it will return. Thanks. -ss sometimes `xset dpms force off' just turns off the panel for a second, sometimes -- until I generate a `wakeup' event (key press, etc.) part of dmesg (no WARNING yet) [ 253.699215] [drm:check_encoder_state] [ENCODER:32:DAC-32] [ 253.699217] [drm:check_encoder_state] [ENCODER:33:TMDS-33] [ 253.699219] [drm:check_encoder_state] [ENCODER:41:TMDS-41] [ 253.699221] [drm:check_crtc_state] [CRTC:21] [ 253.699225] [drm:check_crtc_state] [CRTC:25] [ 253.699226] [drm:check_crtc_state] [CRTC:29] [ 253.699228] [drm:check_shared_dpll_state] WRPLL 1 [ 253.699230] [drm:check_shared_dpll_state] WRPLL 2 [ 253.699270] [drm:intel_backlight_device_update_status] updating intel_backlight, brightness=0/976 [ 256.612288] [drm:drm_mode_setcrtc] [CRTC:21] [ 256.612299] [drm:drm_mode_setcrtc] [CONNECTOR:34:eDP-1] [ 256.612302] [drm:intel_crtc_set_config] [CRTC:21] [FB:45] #connectors=1 (x y) (0 0) [ 256.612308] [drm:intel_modeset_stage_output_state] [CONNECTOR:34:eDP-1] to [CRTC:21] [ 256.612317] [drm:connected_sink_compute_bpp] [CONNECTOR:34:eDP-1] checking for sink bpp constrains [ 256.612318] [drm:connected_sink_compute_bpp] clamping display bpp (was 36) to EDID reported max of 18 [ 256.612322] [drm:intel_dp_compute_config] DP link computation with max lane count 2 max bw 27 pixel clock 143000KHz [ 256.612324] [drm:intel_dp_compute_config] DP link bw 0a lane count 2 clock 27 bpp 18 [ 256.612326] [drm:intel_dp_compute_config] DP link bw required 257400 available 432000 [ 256.612328] [drm:intel_modeset_pipe_config] plane bpp: 36, pipe bpp: 18, dithering: 1 [ 256.612331] [drm:intel_dump_pipe_config] [CRTC:21][modeset] config 8800c6683400 for pipe A [ 256.612332] [drm:intel_dump_pipe_config] cpu_transcoder: D [ 256.612333] [drm:intel_dump_pipe_config] pipe bpp: 18, dithering: 1 [ 256.612335] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 [ 256.612337] [drm:intel_dump_pipe_config] dp: 1, gmch_m: 4998212, gmch_n: 8388608, link_m: 277678, link_n: 524288, tu: 64 [ 256.612339] [drm:intel_dump_pipe_config] dp: 1, gmch_m2: 0, gmch_n2: 0, link_m2: 0, link_n2: 0, tu2: 0 [ 256.612340] [drm:intel_dump_pipe_config] audio: 0, infoframes: 0 [ 256.612342] [drm:intel_dump_pipe_config] requested mode: [ 256.612344] [drm:drm_mode_debug_printmodeline] Modeline 0:1920x1080 60 143000 1920 1968 2000 2080 1080 1082 1087 1144 0x0 0xa [ 256.612346] [drm:intel_dump_pipe_config] adjusted mode: [ 256.612348] [drm:drm_mode_debug_printmodeline] Modeline 0:1920x1080 60 143000 1920 1968 2000 2080 1080 1082 1087 1144 0x48 0xa [ 256.612350] [drm:intel_dump_crtc_timings] crtc timings: 143000 1920 1968 2000 2080 1080 1082 1087 1144, type: 0x48 flags: 0xa [ 256.612351] [drm:intel_dump_pipe_config] port clock: 27 [ 256.612353] [drm:intel_dump_pipe_config] pipe src size: 1920x1080 [ 256.612354] [drm:intel_dump_pipe_config] num_scalers: 0, scaler_users: 0x0, scaler_id: 0 [ 256.612356] [drm:intel_dump_pipe_config] gmch pfit: control: 0x, ratios: 0x, lvds border: 0x [ 256.612358] [drm:intel_dump_pipe_config] pch pfit: pos: 0x, size: 0x, disabled [ 256.612359] [drm:intel_dump_pipe_config] ips: 0 [ 256.612360] [drm:intel_dump_pipe_config] double wide: 0 [ 256.612362] [drm:intel_dump_pipe_config] ddi_pll_sel: 536870912; dpll_hw_state: wrpll: 0x0 [ 256.612363] [drm:intel_dump_pipe_config] planes on this crtc [ 256.612365] [drm:intel_dump_pipe_config] STANDARD PLANE:18 plane: 0.0 idx: 0 enabled [ 256.612367] [drm:intel_dump_pipe_config] FB:45, fb = 1920x1080 format = 0x34325258 [ 256.612369] [drm:intel_dump_pipe_config] scaler:0 src (0, 0) 0x0 dst (0, 0) 0x0 [ 256.612371] [drm:intel_dump_pipe_config] CURSOR PLANE:20 plane: 0.1 idx: 1 disabled, scaler_id = 0 [ 256.612372] [drm:intel_dump_pipe_config] STANDARD PLANE:22 plane: 0.1 idx: 2 disabled, scaler_id = 0 [ 256.612425] [drm:edp_panel_on] Turn eDP port A panel power on [ 256.612429] [drm:wait_panel_power_cycle] Wait for panel power cycle [ 256.612433] [drm:wait_panel_status] mask b80f value status control abcd [ 256.612436] [drm:wait_panel_status] Wait complete [ 256.612441] [drm:wait_panel_on] Wait for panel power on [ 256.612445] [drm:wait_panel_status] mask b00f value 8008 status 000a control abcd0003 [ 256.820170]
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
On (07/15/15 11:51), Michel Dänzer wrote: On 14.07.2015 22:41, Sergey Senozhatsky wrote: sometimes `xset dpms force off' just turns off the panel for a second, sometimes -- until I generate a `wakeup' event (key press, etc.) FWIW, the former case is because releasing the enter key generates an input event, which changes the DPMS state to on again. You can avoid that with something like sleep 1 xset dpms force off. Yeah, sure. That's the expected behaviour. 'turns off the panel for a second' is sort of wrong here. -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
On (07/13/15 17:05), Daniel Vetter wrote: It goes boom somewhere from the cursor ioctl code, which means X is probably involved. Usual suspects are vt-switching, suspend/resume or cursor vs. DPMS. You can force a DPMS off from within X with $ xset dpms force off that helped. seems to be working only on -next. [ 42.409154] [ cut here ] [ 42.409234] WARNING: CPU: 0 PID: 359 at drivers/gpu/drm/i915/i915_gem.c:5368 i915_gem_track_fb+0xdc/0x106 [i915]() [ 42.409239] WARN_ON(new-frontbuffer_bits frontbuffer_bits) [ 42.409243] Modules linked in: [ 42.409248] sha256_ssse3 sha256_generic hmac drbg ctr ccm mousedev arc4 nls_iso8859_1 nls_cp437 coretemp vfat hwmon iwlmvm fat intel_powerclamp crc32c_intel i915 mac80211 psmouse i2c_i801 cfbfillrect cfbimgblt iwlwifi i2c_algo_bit serio_raw cfbcopyarea ie31200_edac lpc_ich atkbd r8169 libps2 mfd_core drm_kms_helper cfg80211 mii drm edac_core thermal mxm_wmi i8042 video serio backlight wmi evdev processor ext4 crc16 mbcache jbd2 sd_mod ehci_pci ehci_hcd ahci libahci libata xhci_pci xhci_hcd scsi_mod usbcore usb_common [ 42.409364] CPU: 0 PID: 359 Comm: Xorg Not tainted 4.2.0-rc2-next-20150713-dbg-00017-g16b87ed-dirty #183 [ 42.409369] 0009 88041ce139d8 813a19ac 81077163 [ 42.409379] 88041ce13a28 88041ce13a18 8103b5d9 88041ce139f8 [ 42.409388] a054b273 0002 88041a938240 88041a938240 [ 42.409397] Call Trace: [ 42.409414] [813a19ac] dump_stack+0x4c/0x65 [ 42.409425] [81077163] ? up+0x39/0x3e [ 42.409433] [8103b5d9] warn_slowpath_common+0x9b/0xb5 [ 42.409486] [a054b273] ? i915_gem_track_fb+0xdc/0x106 [i915] [ 42.409492] [8103b639] warn_slowpath_fmt+0x46/0x48 [ 42.409540] [a054b273] i915_gem_track_fb+0xdc/0x106 [i915] [ 42.409611] [a058d928] intel_prepare_plane_fb+0xb1/0x101 [i915] [ 42.409632] [a027ff0f] drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] [ 42.409700] [a059d596] intel_atomic_commit+0x46/0xc0 [i915] [ 42.409750] [a02f2139] drm_atomic_commit+0x4d/0x52 [drm] [ 42.409769] [a0280f32] drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] [ 42.409811] [a02e7572] __setplane_internal+0x24e/0x2ae [drm] [ 42.409846] [a02e771b] drm_mode_cursor_universal+0x149/0x197 [drm] [ 42.409880] [a02e7e58] ? drm_mode_setcrtc+0x428/0x428 [drm] [ 42.409910] [a02e781e] drm_mode_cursor_common+0xb5/0x156 [drm] [ 42.409939] [a02e7e8f] drm_mode_cursor_ioctl+0x37/0x39 [drm] [ 42.409967] [a02dae85] drm_ioctl+0x287/0x415 [drm] [ 42.409975] [81078580] ? __lock_is_held+0x3c/0x57 [ 42.409983] [8114c3d1] ? __fget+0x170/0x1a1 [ 42.409991] [811422c1] do_vfs_ioctl+0x455/0x4dd [ 42.409996] [8114c48e] ? __fget_light+0x65/0x75 [ 42.410003] [8114238d] SyS_ioctl+0x44/0x63 [ 42.410010] [813a8057] entry_SYSCALL_64_fastpath+0x12/0x6f [ 42.410016] ---[ end trace 90f0a9050a7baa50 ]--- -ss For suspend resume it occasionally matters whether you initiate it through the gui or by closing the lid or through timeout (if you're not connected to a wallplug). I hope this helps with figuring out a repro recipe. It could also be a race somewhere, in which case you won't be able to consistently reproduce this. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
On (07/14/15 14:44), Daniel Vetter wrote: that helped. seems to be working only on -next. You mean you only get a backtrace on -next, right? yeah, sure :-) Otherwise I'd be confused ;-) Next up. Please boot with drm.debug=0xe, repro the issue and attach complete dmesg (from boot-up up to the WARNING). That should help us reconstruct how things went wrong here. can't reproduce it thus far. sometimes `xset dpms force off' just turns off the panel for a second, sometimes -- until I generate a `wakeup' event (key press, etc.) part of dmesg (no WARNING yet) [ 253.699215] [drm:check_encoder_state] [ENCODER:32:DAC-32] [ 253.699217] [drm:check_encoder_state] [ENCODER:33:TMDS-33] [ 253.699219] [drm:check_encoder_state] [ENCODER:41:TMDS-41] [ 253.699221] [drm:check_crtc_state] [CRTC:21] [ 253.699225] [drm:check_crtc_state] [CRTC:25] [ 253.699226] [drm:check_crtc_state] [CRTC:29] [ 253.699228] [drm:check_shared_dpll_state] WRPLL 1 [ 253.699230] [drm:check_shared_dpll_state] WRPLL 2 [ 253.699270] [drm:intel_backlight_device_update_status] updating intel_backlight, brightness=0/976 [ 256.612288] [drm:drm_mode_setcrtc] [CRTC:21] [ 256.612299] [drm:drm_mode_setcrtc] [CONNECTOR:34:eDP-1] [ 256.612302] [drm:intel_crtc_set_config] [CRTC:21] [FB:45] #connectors=1 (x y) (0 0) [ 256.612308] [drm:intel_modeset_stage_output_state] [CONNECTOR:34:eDP-1] to [CRTC:21] [ 256.612317] [drm:connected_sink_compute_bpp] [CONNECTOR:34:eDP-1] checking for sink bpp constrains [ 256.612318] [drm:connected_sink_compute_bpp] clamping display bpp (was 36) to EDID reported max of 18 [ 256.612322] [drm:intel_dp_compute_config] DP link computation with max lane count 2 max bw 27 pixel clock 143000KHz [ 256.612324] [drm:intel_dp_compute_config] DP link bw 0a lane count 2 clock 27 bpp 18 [ 256.612326] [drm:intel_dp_compute_config] DP link bw required 257400 available 432000 [ 256.612328] [drm:intel_modeset_pipe_config] plane bpp: 36, pipe bpp: 18, dithering: 1 [ 256.612331] [drm:intel_dump_pipe_config] [CRTC:21][modeset] config 8800c6683400 for pipe A [ 256.612332] [drm:intel_dump_pipe_config] cpu_transcoder: D [ 256.612333] [drm:intel_dump_pipe_config] pipe bpp: 18, dithering: 1 [ 256.612335] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 [ 256.612337] [drm:intel_dump_pipe_config] dp: 1, gmch_m: 4998212, gmch_n: 8388608, link_m: 277678, link_n: 524288, tu: 64 [ 256.612339] [drm:intel_dump_pipe_config] dp: 1, gmch_m2: 0, gmch_n2: 0, link_m2: 0, link_n2: 0, tu2: 0 [ 256.612340] [drm:intel_dump_pipe_config] audio: 0, infoframes: 0 [ 256.612342] [drm:intel_dump_pipe_config] requested mode: [ 256.612344] [drm:drm_mode_debug_printmodeline] Modeline 0:1920x1080 60 143000 1920 1968 2000 2080 1080 1082 1087 1144 0x0 0xa [ 256.612346] [drm:intel_dump_pipe_config] adjusted mode: [ 256.612348] [drm:drm_mode_debug_printmodeline] Modeline 0:1920x1080 60 143000 1920 1968 2000 2080 1080 1082 1087 1144 0x48 0xa [ 256.612350] [drm:intel_dump_crtc_timings] crtc timings: 143000 1920 1968 2000 2080 1080 1082 1087 1144, type: 0x48 flags: 0xa [ 256.612351] [drm:intel_dump_pipe_config] port clock: 27 [ 256.612353] [drm:intel_dump_pipe_config] pipe src size: 1920x1080 [ 256.612354] [drm:intel_dump_pipe_config] num_scalers: 0, scaler_users: 0x0, scaler_id: 0 [ 256.612356] [drm:intel_dump_pipe_config] gmch pfit: control: 0x, ratios: 0x, lvds border: 0x [ 256.612358] [drm:intel_dump_pipe_config] pch pfit: pos: 0x, size: 0x, disabled [ 256.612359] [drm:intel_dump_pipe_config] ips: 0 [ 256.612360] [drm:intel_dump_pipe_config] double wide: 0 [ 256.612362] [drm:intel_dump_pipe_config] ddi_pll_sel: 536870912; dpll_hw_state: wrpll: 0x0 [ 256.612363] [drm:intel_dump_pipe_config] planes on this crtc [ 256.612365] [drm:intel_dump_pipe_config] STANDARD PLANE:18 plane: 0.0 idx: 0 enabled [ 256.612367] [drm:intel_dump_pipe_config] FB:45, fb = 1920x1080 format = 0x34325258 [ 256.612369] [drm:intel_dump_pipe_config] scaler:0 src (0, 0) 0x0 dst (0, 0) 0x0 [ 256.612371] [drm:intel_dump_pipe_config] CURSOR PLANE:20 plane: 0.1 idx: 1 disabled, scaler_id = 0 [ 256.612372] [drm:intel_dump_pipe_config] STANDARD PLANE:22 plane: 0.1 idx: 2 disabled, scaler_id = 0 [ 256.612425] [drm:edp_panel_on] Turn eDP port A panel power on [ 256.612429] [drm:wait_panel_power_cycle] Wait for panel power cycle [ 256.612433] [drm:wait_panel_status] mask b80f value status control abcd [ 256.612436] [drm:wait_panel_status] Wait complete [ 256.612441] [drm:wait_panel_on] Wait for panel power on [ 256.612445] [drm:wait_panel_status] mask b00f value 8008 status 000a control abcd0003 [ 256.820170] [drm:wait_panel_status] Wait complete [ 256.820188] [drm:edp_panel_vdd_on] Turning eDP port A VDD on [ 256.820198] [drm:edp_panel_vdd_on] PP_STATUS: 0x8008 PP_CONTROL:
[Intel-gfx] [-next] WARNING at i915_gem_track_fb
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 frontbuffer_bits) [ 1239.783895] Modules linked in: [ 1239.783897] zram lz4_decompress lz4_compress lzo_compress lzo_decompress zsmalloc sha256_ssse3 sha256_generic hmac drbg ctr ccm mousedev arc4 nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon iwlmvm i915 mac80211 cfbfillrect cfbimgblt intel_powerclamp i2c_algo_bit crc32c_intel iwlwifi i2c_i801 serio_raw cfbcopyarea psmouse drm_kms_helper ie31200_edac cfg80211 lpc_ich r8169 atkbd mfd_core mii thermal drm edac_core libps2 mxm_wmi wmi i8042 evdev video serio backlight processor ext4 crc16 mbcache jbd2 sd_mod ehci_pci ehci_hcd ahci libahci libata xhci_pci xhci_hcd scsi_mod usbcore usb_common [ 1239.783942] CPU: 0 PID: 364 Comm: Xorg Not tainted 4.2.0-rc2-next-20150713-dbg-00017-g16b87ed-dirty #183 [ 1239.783944] 0009 88041c5379d8 813a19ac 81077163 [ 1239.783947] 88041c537a28 88041c537a18 8103b5d9 88041c5379f8 [ 1239.783950] a0533273 0002 88041c578000 88041c578000 [ 1239.783953] Call Trace: [ 1239.783961] [813a19ac] dump_stack+0x4c/0x65 [ 1239.783965] [81077163] ? up+0x39/0x3e [ 1239.783968] [8103b5d9] warn_slowpath_common+0x9b/0xb5 [ 1239.783986] [a0533273] ? i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.783987] [8103b639] warn_slowpath_fmt+0x46/0x48 [ 1239.784002] [a0533273] i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.784026] [a0575928] intel_prepare_plane_fb+0xb1/0x101 [i915] [ 1239.784033] [a0261f0f] drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] [ 1239.784055] [a0585596] intel_atomic_commit+0x46/0xc0 [i915] [ 1239.784072] [a02d2139] drm_atomic_commit+0x4d/0x52 [drm] [ 1239.784078] [a0262f32] drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] [ 1239.784092] [a02c7572] __setplane_internal+0x24e/0x2ae [drm] [ 1239.784103] [a02c771b] drm_mode_cursor_universal+0x149/0x197 [drm] [ 1239.784113] [a02c7e58] ? drm_mode_setcrtc+0x428/0x428 [drm] [ 1239.784122] [a02c781e] drm_mode_cursor_common+0xb5/0x156 [drm] [ 1239.784132] [a02c7e8f] drm_mode_cursor_ioctl+0x37/0x39 [drm] [ 1239.784140] [a02bae85] drm_ioctl+0x287/0x415 [drm] [ 1239.784143] [81078580] ? __lock_is_held+0x3c/0x57 [ 1239.784146] [8114c3d1] ? __fget+0x170/0x1a1 [ 1239.784148] [811422c1] do_vfs_ioctl+0x455/0x4dd [ 1239.784151] [8114c48e] ? __fget_light+0x65/0x75 [ 1239.784153] [8114238d] SyS_ioctl+0x44/0x63 [ 1239.784155] [813a8057] entry_SYSCALL_64_fastpath+0x12/0x6f [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
On (07/13/15 16:35), Daniel Vetter wrote: On Mon, Jul 13, 2015 at 09:51:39PM +0900, Sergey Senozhatsky wrote: 4.2.0-rc2-next-20150713 Is this also an issue in the 4.2-rc series or only in -next? don't know how to reproduce this, but I'll check. -ss [ 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 frontbuffer_bits) [ 1239.783895] Modules linked in: [ 1239.783897] zram lz4_decompress lz4_compress lzo_compress lzo_decompress zsmalloc sha256_ssse3 sha256_generic hmac drbg ctr ccm mousedev arc4 nls_iso8859_1 nls_cp437 vfat fat coretemp hwmon iwlmvm i915 mac80211 cfbfillrect cfbimgblt intel_powerclamp i2c_algo_bit crc32c_intel iwlwifi i2c_i801 serio_raw cfbcopyarea psmouse drm_kms_helper ie31200_edac cfg80211 lpc_ich r8169 atkbd mfd_core mii thermal drm edac_core libps2 mxm_wmi wmi i8042 evdev video serio backlight processor ext4 crc16 mbcache jbd2 sd_mod ehci_pci ehci_hcd ahci libahci libata xhci_pci xhci_hcd scsi_mod usbcore usb_common [ 1239.783942] CPU: 0 PID: 364 Comm: Xorg Not tainted 4.2.0-rc2-next-20150713-dbg-00017-g16b87ed-dirty #183 [ 1239.783944] 0009 88041c5379d8 813a19ac 81077163 [ 1239.783947] 88041c537a28 88041c537a18 8103b5d9 88041c5379f8 [ 1239.783950] a0533273 0002 88041c578000 88041c578000 [ 1239.783953] Call Trace: [ 1239.783961] [813a19ac] dump_stack+0x4c/0x65 [ 1239.783965] [81077163] ? up+0x39/0x3e [ 1239.783968] [8103b5d9] warn_slowpath_common+0x9b/0xb5 [ 1239.783986] [a0533273] ? i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.783987] [8103b639] warn_slowpath_fmt+0x46/0x48 [ 1239.784002] [a0533273] i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.784026] [a0575928] intel_prepare_plane_fb+0xb1/0x101 [i915] [ 1239.784033] [a0261f0f] drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] [ 1239.784055] [a0585596] intel_atomic_commit+0x46/0xc0 [i915] [ 1239.784072] [a02d2139] drm_atomic_commit+0x4d/0x52 [drm] [ 1239.784078] [a0262f32] drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] [ 1239.784092] [a02c7572] __setplane_internal+0x24e/0x2ae [drm] [ 1239.784103] [a02c771b] drm_mode_cursor_universal+0x149/0x197 [drm] [ 1239.784113] [a02c7e58] ? drm_mode_setcrtc+0x428/0x428 [drm] [ 1239.784122] [a02c781e] drm_mode_cursor_common+0xb5/0x156 [drm] [ 1239.784132] [a02c7e8f] drm_mode_cursor_ioctl+0x37/0x39 [drm] [ 1239.784140] [a02bae85] drm_ioctl+0x287/0x415 [drm] [ 1239.784143] [81078580] ? __lock_is_held+0x3c/0x57 [ 1239.784146] [8114c3d1] ? __fget+0x170/0x1a1 [ 1239.784148] [811422c1] do_vfs_ioctl+0x455/0x4dd [ 1239.784151] [8114c48e] ? __fget_light+0x65/0x75 [ 1239.784153] [8114238d] SyS_ioctl+0x44/0x63 [ 1239.784155] [813a8057] entry_SYSCALL_64_fastpath+0x12/0x6f [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [-next] WARNING at i915_gem_track_fb
On (07/13/15 16:46), Maarten Lankhorst wrote: [ 1239.783961] [813a19ac] dump_stack+0x4c/0x65 [ 1239.783965] [81077163] ? up+0x39/0x3e [ 1239.783968] [8103b5d9] warn_slowpath_common+0x9b/0xb5 [ 1239.783986] [a0533273] ? i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.783987] [8103b639] warn_slowpath_fmt+0x46/0x48 [ 1239.784002] [a0533273] i915_gem_track_fb+0xdc/0x106 [i915] [ 1239.784026] [a0575928] intel_prepare_plane_fb+0xb1/0x101 [i915] [ 1239.784033] [a0261f0f] drm_atomic_helper_prepare_planes+0x5b/0xb8 [drm_kms_helper] [ 1239.784055] [a0585596] intel_atomic_commit+0x46/0xc0 [i915] [ 1239.784072] [a02d2139] drm_atomic_commit+0x4d/0x52 [drm] [ 1239.784078] [a0262f32] drm_atomic_helper_update_plane+0xca/0x119 [drm_kms_helper] [ 1239.784092] [a02c7572] __setplane_internal+0x24e/0x2ae [drm] [ 1239.784103] [a02c771b] drm_mode_cursor_universal+0x149/0x197 [drm] [ 1239.784113] [a02c7e58] ? drm_mode_setcrtc+0x428/0x428 [drm] [ 1239.784122] [a02c781e] drm_mode_cursor_common+0xb5/0x156 [drm] [ 1239.784132] [a02c7e8f] drm_mode_cursor_ioctl+0x37/0x39 [drm] [ 1239.784140] [a02bae85] drm_ioctl+0x287/0x415 [drm] [ 1239.784143] [81078580] ? __lock_is_held+0x3c/0x57 [ 1239.784146] [8114c3d1] ? __fget+0x170/0x1a1 [ 1239.784148] [811422c1] do_vfs_ioctl+0x455/0x4dd [ 1239.784151] [8114c48e] ? __fget_light+0x65/0x75 [ 1239.784153] [8114238d] SyS_ioctl+0x44/0x63 [ 1239.784155] [813a8057] entry_SYSCALL_64_fastpath+0x12/0x6f [ 1239.784157] ---[ end trace 67b32b389e7fe7df ]--- Do you have some steps to reproduce? Unfortunately no. -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [i915]] *ERROR* mismatch in scaler_state.scaler_id
On (05/08/15 01:27), Konduru, Chandra wrote: there are no specific steps, happens during boot and every time the screen goes unblank. attached dmesg, .config. OK, I am able reproduce the mismatch scaler id log on HSW system. Though, this log doesn't affect system functionality, but it is an unnecessary annoyance. This check is targeted for SKL and shouldn't happen for HSW. Submitted a patch to limit the check for skl+: http://patchwork.freedesktop.org/patch/48858/ jfi, the usual patch exchange happens in mailing lists. `git am email' vs. `browsing some pages and downloading attached patches'. back to the patch: no more mismatch warnings. Reported-and-tested-by: Sergey Senozhatsky sergey.senozhat...@gmail.com -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i915]] *ERROR* mismatch in scaler_state.scaler_id
Hi, linux-next 20150501 [1.968953] [drm:check_crtc_state [i915]] *ERROR* mismatch in scaler_state.scaler_id (expected 0, found -1) [1.968953] [ cut here ] [1.968983] WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/i915/intel_display.c:12008 check_crtc_state+0xb15/0xb83 [i915]() [1.968983] pipe state doesn't match! [..] [1.969005] CPU: 0 PID: 6 Comm: kworker/u16:0 Not tainted 4.1.0-rc1-next-20150501-dbg-00011-gbcb7bed-dirty #49 [1.969010] Workqueue: events_unbound async_run_entry_fn [1.969012] 0009 88041d9eb448 812e9753 [1.969013] 88041d9eb498 88041d9eb488 81034c24 88041d9eb490 [1.969015] a03a81dc 88041d123000 88041cbbc800 0001 [1.969015] Call Trace: [1.969019] [812e9753] dump_stack+0x45/0x57 [1.969022] [81034c24] warn_slowpath_common+0x97/0xb1 [1.969050] [a03a81dc] ? check_crtc_state+0xb15/0xb83 [i915] [1.969052] [81034c7f] warn_slowpath_fmt+0x41/0x43 [1.969080] [a03a81dc] check_crtc_state+0xb15/0xb83 [i915] [1.969082] [81054941] ? update_curr+0x68/0xd1 [1.969112] [a03b6ab6] intel_modeset_check_state+0x603/0xa3d [i915] [1.969140] [a03b7db5] intel_crtc_set_config+0x8dc/0xc02 [i915] [1.969147] [a0310d51] ? drm_atomic_helper_plane_set_property+0x6c/0xa4 [drm_kms_helper] [1.969159] [a02688d2] drm_mode_set_config_internal+0x57/0xe3 [drm] [1.969164] [a03122fa] restore_fbdev_mode+0xb5/0xcf [drm_kms_helper] [1.969169] [a0313bb3] drm_fb_helper_restore_fbdev_mode_unlocked+0x22/0x59 [drm_kms_helper] [1.969173] [a0313c1b] drm_fb_helper_set_par+0x31/0x35 [drm_kms_helper] [1.969202] [a03c4151] intel_fbdev_set_par+0x15/0x58 [i915] [1.969204] [811a3577] fbcon_init+0x323/0x431 [1.969206] [811ef80a] visual_init+0xb7/0x10d [1.969208] [811f0e26] do_bind_con_driver+0x1b1/0x2d8 [1.969209] [811f124f] do_take_over_console+0x15a/0x184 [1.969212] [811a15e7] do_fbcon_takeover+0x5b/0x97 [1.969213] [811a4dc5] fbcon_event_notify+0x419/0x740 [1.969215] [810492cc] notifier_call_chain+0x3b/0x5f [1.969217] [8104950a] __blocking_notifier_call_chain+0x43/0x5f [1.969219] [81049535] blocking_notifier_call_chain+0xf/0x11 [1.969220] [811a68f8] fb_notifier_call_chain+0x16/0x18 [1.969222] [811a8134] register_framebuffer+0x28f/0x2c7 [1.969250] [a03c45a3] ? intelfb_create+0x2e7/0x38a [i915] [1.969256] [a0313eb6] drm_fb_helper_initial_config+0x297/0x3e1 [drm_kms_helper] [1.969284] [a03c4a9a] intel_fbdev_initial_config+0x16/0x18 [i915] [1.969286] [8104a177] async_run_entry_fn+0x33/0xca [1.969288] [8104408c] process_one_work+0x192/0x2a8 [1.969290] [81044be8] worker_thread+0x266/0x34c [1.969291] [81044982] ? rescuer_thread+0x276/0x276 [1.969293] [81048908] kthread+0xcd/0xd5 [1.969294] [8104883b] ? kthread_worker_fn+0x130/0x130 [1.969296] [812ed5c2] ret_from_fork+0x42/0x70 [1.969297] [8104883b] ? kthread_worker_fn+0x130/0x130 [1.969298] ---[ end trace 7f37d8e5ab4ee0a8 ]--- -ss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
