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;
> +
> +
On (22/06/01 16:38), Christian König wrote:
> > > Well, you don't.
> > >
> > > If you have a dynamic context structure you need to reference count that
> > > as
> > > well. In other words every time you create a fence in your context you
> > > need
> > > to increment the reference count and
On (22/06/01 14:45), Christian König wrote:
> Am 31.05.22 um 04:51 schrieb Sergey Senozhatsky:
> > On (22/05/30 16:55), Christian König wrote:
> > > Am 30.05.22 um 16:22 schrieb Sergey Senozhatsky:
> > > > [SNIP]
> > > > So the `lock` should ha
On (22/05/30 16:55), Christian König wrote:
> Am 30.05.22 um 16:22 schrieb Sergey Senozhatsky:
> > [SNIP]
> > So the `lock` should have at least same lifespan as the DMA fence
> > that borrows it, which is impossible to guarantee in our case.
>
> Nope, that's not co
On (22/05/30 16:55), Christian König wrote:
>
> If you just want to create a single dma_fence which is also only bound to a
> single context you can embed the lock into the fence without much problem.
>
> See how the dma_fence_array does that for example:
>
Hi Christian,
On (22/05/30 16:55), Christian König wrote:
> Hi Sergey,
>
> I'm removing most of the mail because you have a very fundamental
> misunderstanding about what this dma_fence lock is all about.
Happy to learn.
> Am 30.05.22 um 16:22 schrieb Sergey Senozhatsky:
&g
e lock.
But after seeing how owten drivers directly access fence ->lock I
decided to scratch that approach and just add extra spinlock member.
Not-Yet-Signed-off-by: Sergey Senozhatsky
---
drivers/dma-buf/dma-fence.c | 10 ++
include/linux/dma-fence.h | 6 ++
2 files ch
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
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
On (21/02/02 16:02), Masahiro Yamada wrote:
>
> CONSOLE_LOGLEVEL_DEFAULT is nothing more than a shorthand of
> CONFIG_CONSOLE_LOGLEVEL_DEFAULT.
>
> When you change CONFIG_CONSOLE_LOGLEVEL_DEFAULT from Kconfig, almost
> all objects are rebuilt because CONFIG_CONSOLE_LOGLEVEL_DEFAULT is
> used in
mentation can be used.
> >
> > Suggested-by: Mauro Carvalho Chehab
> > Signed-off-by: Sakari Ailus
>
> The last version looks fine to me.
>
> Reviewed-by: Petr Mladek
Reviewed-by: Sergey Senozhatsky
-ss
___
dri-devel
We observed that some of virtio_gpu_object_shmem_init() allocations
can be rather costly - order 6 - which can be difficult to fulfill
under memory pressure conditions. Switch to kvmalloc_array() in
virtio_gpu_object_shmem_init() and let the kernel vmalloc the entries
array.
Signed-off-by: Sergey
Hi,
On (20/11/05 07:52), Gerd Hoffmann wrote:
> > - *ents = kmalloc_array(*nents, sizeof(struct virtio_gpu_mem_entry),
> > - GFP_KERNEL);
> > + *ents = kvmalloc_array(*nents,
> > + sizeof(struct virtio_gpu_mem_entry),
> > +
On (20/09/29 17:09), Peter Zijlstra wrote:
> > 2. The registration and unregistration of consoles should not longer
> >be handled by console_lock (semaphore). It should be possible to
> >call most consoles without a sleeping lock. It should remove all
> >these deadlocks between
On (20/09/28 12:25), Peter Zijlstra wrote:
[..]
> > printk
> > vprintk_emit
> > console_unlock
> > vt_console_print
> > hide_cursor
> > bit_cursor
> > soft_cursor
> > queue_work_on
> > __queue_work
> >
On (20/04/09 10:08), Minchan Kim wrote:
> > > Even though I don't know how many usecase we have using zsmalloc as
> > > module(I heard only once by dumb reason), it could affect existing
> > > users. Thus, please include concrete explanation in the patch to
> > > justify when the complain occurs.
Cc-ing Dmitry and Tetsuo
Original Message-id:
CAA=061eow8amjurblsjy5ntdz-1jearleb+z6hjuyzud0zz...@mail.gmail.com
On (20/01/29 23:17), Sergey Senozhatsky wrote:
> > Hmm. There is something strange about it. I use vga console quite
> > often, and scrolling happens all the time, yet
On (20/01/29 23:15), Sergey Senozhatsky wrote:
> Date: Wed, 29 Jan 2020 23:15:17 +0900
> From: Sergey Senozhatsky
> To: Bartlomiej Zolnierkiewicz
> Cc: Petr Mladek , anon anon <742991625...@gmail.com>,
> wangkefeng.w...@huawei.com, sergey.senozhat...@gmail.com,
> sy
On (20/01/28 15:58), Bartlomiej Zolnierkiewicz wrote:
[..]
>
> Help is welcomed as I'm not going to look at it in the foreseeable future
> (I'm busy enough with other things).
>
> > (dri-devel@lists.freedesktop.org or linux-fb...@vger.kernel.org) into CC?
>
> Added to Cc:, thanks.
Hmm. There
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
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
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
x60
__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 f
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
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
() 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
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
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.
&
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
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
x60
__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(+)
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
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;
> &g
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:
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
On (06/19/19 02:07), Ilia Mirkin wrote:
> If all else fails, just remove nouveau_dri.so and/or boot with
> nouveau.noaccel=1 -- should be perfect.
nouveau.noaccel=1 did the trick. Is there any other, let's say
less CPU-intensive, way to fix nouveau?
-ss
On (06/19/19 15:27), Sergey Senozhatsky wrote:
> [..]
>
> > If all else fails, just remove nouveau_dri.so and/or boot with
> > nouveau.noaccel=1 -- should be perfect.
>
> Can give it a try.
That has some impact on system responsiveness:
CPU% COMM
339.7
On (06/19/19 02:07), Ilia Mirkin wrote:
> On Wed, Jun 19, 2019 at 1:48 AM Sergey Senozhatsky
> wrote:
> >
> > On (06/19/19 01:20), Ilia Mirkin wrote:
> > > On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
> > > wrote:
> > > >
>
On (06/14/19 11:50), Sergey Senozhatsky wrote:
> dmesg
>
> nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon
> nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
> nouveau :01:00.0: fifo: runlist 0: scheduled for recovery
> nouveau :01:00.
On (06/19/19 01:20), Ilia Mirkin wrote:
> On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
> wrote:
> >
> > On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > > dmesg
> > >
> > > nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon
&
5.2.0-rc4-next-20190613
dmesg
nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon
nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
nouveau :01:00.0: fifo: runlist 0: scheduled for recovery
nouveau :01:00.0: fifo: channel 5: killed
nouveau :01:00.0:
On (05/17/19 15:31), Sergey Senozhatsky wrote:
> > backtrace:
> > [<81f2894f>] nvkm_memory_tags_get+0x8e/0x130
> > [<7cd7c0bc>] gf100_vmm_valid+0x196/0x2f0
> > [<70cc6d67>] nvkm_vmm_map+0xa8/0x360
>
On (05/17/19 16:27), Sergey Senozhatsky wrote:
> > ... but most likely it's utterly wrong.
> >
>
> JFI, I removed kmemleak annotation
meeehhh
kmemleak: 2046 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
unreferenced object 0x95cbea4e6060 (size 16):
On (05/17/19 15:13), Sergey Senozhatsky wrote:
> 5.1.0-next-20190517
>
> I'm looking at quite a lot of kmemleak reports coming from
> drm/nouveau/core/memory, all of which are:
>
> unreferenced object 0x8deec27c4ac0 (size 16):
> comm "Web Content", pi
Hello,
5.1.0-next-20190517
I'm looking at quite a lot of kmemleak reports coming from
drm/nouveau/core/memory, all of which are:
unreferenced object 0x8deec27c4ac0 (size 16):
comm "Web Content", pid 5309, jiffies 4309675011 (age 68.076s)
hex dump (first 16 bytes):
00
On (05/17/19 15:13), Sergey Senozhatsky wrote:
> ... but most likely it's utterly wrong.
>
JFI, I removed kmemleak annotation and added the following
thing:
@@ -360,6 +360,7 @@ gp100_vmm_valid(struct nvkm_vmm *vmm, void *argv, u32 argc,
return -
On (05/10/19 11:15), Petr Mladek wrote:
[..]
> arch/x86/kernel/smp.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- a/arch/x86/kernel/smp.c
> +++ b/arch/x86/kernel/smp.c
> @@ -124,7 +124,8 @@ static bool smp_no_nmi_ipi = false;
> */
> static void
On (05/09/19 22:06), Daniel Vetter wrote:
[..]
> +/* Functions for the contended case */
> +
> +struct semaphore_waiter {
> + struct list_head list;
> + struct task_struct *task;
> + bool up;
> +};
> +
> /**
> * up - release the semaphore
> * @sem: the semaphore to release
> @@
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.
On (01/10/19 14:03), Prarit Bhargava wrote:
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -649,11 +649,14 @@ static void fbcon_prepare_logo(struct vc_data *vc,
> struct fb_info *info,
> kfree(save);
> }
>
> + if (logo_shown == FBCON_LOGO_DONTSHOW)
> + return;
On (01/10/19 14:03), Prarit Bhargava wrote:
> The fbcon code can be built as a module and requires console_printk.
>
> Export console_printk.
>
> Signed-off-by: Prarit Bhargava
> Cc: Petr Mladek
> Cc: Sergey Senozhatsky
> Cc: Hans de Goede
> Cc: Marko Myllynen
&
On (12/20/18 17:31), Bartlomiej Zolnierkiewicz wrote:
[..]
> > +++ b/kernel/printk/printk.c
> > @@ -66,6 +66,7 @@ int console_printk[4] = {
> > CONSOLE_LOGLEVEL_MIN, /* minimum_console_loglevel */
> > CONSOLE_LOGLEVEL_DEFAULT, /* default_console_loglevel */
> > };
> >
On (09/06/18 12:46), Ben Skeggs wrote:
> On Thu, Sep 6, 2018 at 12:42 PM Sergey Senozhatsky
> wrote:
> >
> > On (08/02/18 11:46), Sergey Senozhatsky wrote:
> > > Hi,
> > >
> > > My dmesg is filled up with these errors
> > >
> > > nou
On (08/02/18 11:46), Sergey Senozhatsky wrote:
> Hi,
>
> My dmesg is filled up with these errors
>
> nouveau :01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1
> nouveau :01:00.0: DRM: DDC responded, but no EDID for VGA-1
> nouveau :01:00.0: DRM: DDC r
Hi,
My dmesg is filled up with these errors
nouveau :01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1
nouveau :01:00.0: DRM: DDC responded, but no EDID for VGA-1
nouveau :01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1
nouveau :01:00.0: DRM: DDC responded, but no
mic_t
> v2:
> - restore ignore_console_lock_warning if lock_fb_info() fails
Reviewed-by: Sergey Senozhatsky
-ss
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi,
On (07/19/18 12:20), Thomas Zimmermann wrote:
> Am 19.07.2018 um 12:05 schrieb Sergey Senozhatsky:
> > On (07/19/18 10:53), Petr Mladek wrote:
> >> Hmm, this approach is racy if there are other users
> >> saving/setting/restoring ignore_console_lock_warni
On (07/19/18 10:53), Petr Mladek wrote:
> Hmm, this approach is racy if there are other users
> saving/setting/restoring ignore_console_lock_warning in parallel.
> I mean that this works only when the entire safe/set/restore
> operation is nested or sequential.
Good point!
However, I tend to
Hi,
On (07/11/18 16:46), Thomas Zimmermann wrote:
> Am 28.06.2018 um 11:03 schrieb Hans de Goede:
> > Replace comments about places where the console lock should be held with
> > calls to WARN_CONSOLE_UNLOCKED() to assert that it is actually held.
>
> Debugging fbcon sometimes requires to not
On (07/03/18 12:14), Steven Rostedt wrote:
> > Can we please default this to 'n'?
> >
>
> No explicit default means 'n'. You don't need to specify it.
Ah, OK. Thanks.
-ss
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On (06/28/18 11:03), Hans de Goede wrote:
[..]
>
> +config FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> + bool "Framebuffer Console Deferred Takeover"
> + depends on FRAMEBUFFER_CONSOLE=y && DUMMY_CONSOLE=y
+ default n
> + help
> + If enabled this defers the framebuffer
On (06/26/18 20:36), Hans de Goede wrote:
> Replace comments about places where the console lock should be held with
> calls to WARN_CONSOLE_UNLOCKED() to assert that it is actually held.
>
> Reviewed-by: Daniel Vetter
> Signed-off-by: Hans de Goede
Reviewed-by: Ser
On (06/26/18 20:36), Hans de Goede wrote:
> This is a preparation patch for adding a number of WARN_CONSOLE_UNLOCKED()
> calls to the fbcon code, which may be built as a module (event though
> usually it is not).
>
> Reviewed-by: Daniel Vetter
> Signed-off-by: Hans de Goede
Hello,
after commit 669c9215afea4e ("drm/atomic: Make async plane update
checks work as intended") drm_atomic_helper_async_check() can NULL
deference the `new_plane_state' pointer and crashe the kernel at
'new_plane_state->crtc':
BUG: unable to handle kernel NULL pointer dereference at
On (07/11/17 11:31), Sergey Senozhatsky wrote:
[..]
> (replying to both Petr and Daniel)
>
> interesting direction, gents.
>
> and this is what I thought about over the weekend; it's very sketchy and
> I didn't spend too much time on it. (I'm on a sick leave now, sorry).
>
On (07/11/17 09:50), Daniel Vetter wrote:
[..]
> > ok, obviously stupid.
> >
> > I meant to hold con->lock between console_disable() and console_enable().
> > so no other CPU can unregister it, etc. printk->console_unlock(), thus,
> > can either have a racy con->flags check (no con->lock taken)
Hello,
On (07/10/17 20:07), Daniel Vetter wrote:
[..]
> > Would it be acceptable to remove "console=tty0" parameter and push
> > the messages only to the serial console?
> >
> > Also there is the patchset from Peter Zijlstra that allows to
> > use early console all the time, see
> >
Hello,
On (07/08/17 22:30), Tetsuo Handa wrote:
> Hmm... should we consider addressing console_sem problem before
> introducing printing kernel thread and offloading to that kernel
> thread?
printk-kthread addresses a completely different set of problems.
console_sem is hard to fix quickly,
Hello,
(Cc Daniel)
On (07/06/17 19:28), Tetsuo Handa wrote:
> (...snipped...)
> [ 912.892027] kworker/3:3 D12120 3217 2 0x0080
> [ 912.892041] Workqueue: events console_callback
> [ 912.892042] Call Trace:
> [ 912.892047] __schedule+0x23f/0x5d0
> [ 912.892051]
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] --
[
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] --
[
Hello,
[2.375503] ==
[2.375504] [ INFO: possible circular locking dependency detected ]
[2.375505] 4.7.0-next-20160727-dbg-4-g32e4851-dirty #770 Not tainted
[2.375506] ---
[
On (03/15/16 07:43), Wolfram Sang wrote:
> > Hello,
> >
> > I'm seeing a bunch of warnings and errors
>
> I pushed the fix to my for-next branch yesterday. Sorry for the fuzz!
no prob, thanks!
-ss
On (03/14/16 17:40), Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20160311:
>
> The vfs tree gained a conflict against Linus' tree. I also applied a
> patch for a known runtime bug.
>
> The tip tree gained a conflict against the mips tree.
>
> The aio tree still had a build failure so I
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
Hi,
rc6-next-20150813
[1.987833] fbcon: inteldrmfb (fb0) is primary device
[1.988589] [ cut here ]
[1.988607] WARNING: CPU: 0 PID: 62 at include/linux/ww_mutex.h:158
drm_atomic_check_only+0x24e/0x4ed [drm]()
[1.988609]
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
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
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
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
On (07/13/15 16:46), Maarten Lankhorst wrote:
> > [ 1239.783961] [] dump_stack+0x4c/0x65
> > [ 1239.783965] [] ? up+0x39/0x3e
> > [ 1239.783968] [] warn_slowpath_common+0x9b/0xb5
> > [ 1239.783986] [] ? i915_gem_track_fb+0xdc/0x106 [i915]
> > [ 1239.783987] [] warn_slowpath_fmt+0x46/0x48
> >
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
> &g
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:
[
On (05/20/15 10:09), Jani Nikula wrote:
> > drm_property_unreference_blob_locked() is static and unused,
> > drop it.
>
> http://mid.gmane.org/CAPj87rMPtafeYNzgXoP+fx0dAqhwaD7kdnJgqb_vdbPtiOrXPg at
> mail.gmail.com
>
oh, ok. thanks.
-ss
> >
> &g
drm_property_unreference_blob_locked() is static and unused,
drop it.
Signed-off-by: Sergey Senozhatsky
---
drivers/gpu/drm/drm_crtc.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 4059f06..6e60f71 100644
sts.
`git am ' vs. `browsing some pages and downloading attached patches'.
back to the patch: no more mismatch warnings.
Reported-and-tested-by: Sergey Senozhatsky
-ss
On (05/07/15 00:40), Konduru, Chandra wrote:
>
> Hi,
> This error happens when crtc_state in driver not matching with hardware
> registers.
> On skylake board that I have, I am not able to reproduce the issue.
> Can you send the system configuration and steps to reproduce the issue?
> Also can
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
On (03/21/14 13:49), Sergey Senozhatsky wrote:
> On (03/21/14 13:37), Sergey Senozhatsky wrote:
> > [ 18.707077] WARNING: CPU: 2 PID: 175 at drivers/gpu/drm/drm_modes.c:1030
> > drm_mode_connector_list_update+0x2f/0xe8 [drm]()
> >
> [ 18.704470] WARNING: CPU: 2 PID
On (03/21/14 13:37), Sergey Senozhatsky wrote:
> [ 18.707077] WARNING: CPU: 2 PID: 175 at drivers/gpu/drm/drm_modes.c:1030
> drm_mode_connector_list_update+0x2f/0xe8 [drm]()
>
[ 18.704470] WARNING: CPU: 2 PID: 175 at drivers/gpu/drm/drm_modes.c:119
drm_mode_probed_add+0x2b/
Hello,
[ 18.707077] WARNING: CPU: 2 PID: 175 at drivers/gpu/drm/drm_modes.c:1030
drm_mode_connector_list_update+0x2f/0xe8 [drm]()
[ 18.707086] Modules linked in: crc32c_intel microcode radeon(+) broadcom
i2c_algo_bit psmouse drm_kms_helper tg3 ttm drm evdev wmi button battery
processor ac
On (12/12/13 23:29), Deucher, Alexander wrote:
> Fix is already queued in my next -fixes pull. Thanks!
>
Nice. Thanks!
-ss
> Alex
>
> > -Original Message-
> > From: Sergey Senozhatsky [mailto:sergey.senozhatsky at gmail.com]
> > Sent: Thurs
[] ? set_memory_nx+0x3b/0x3d
[] load_module+0x1583/0x1bb4
[] ? store_uevent+0x35/0x35
[] ? finish_task_switch+0x3b/0x10c
[] ? preempt_schedule_irq+0x5d/0x99
[] ? retint_restore_args+0x13/0x13
[] SyS_init_module+0xa0/0xaf
[] tracesys+0xd4/0xd9
Signed-off-by: Sergey Senozhatsky
On (08/29/13 16:06), Alex Deucher wrote:
> On Thu, Aug 29, 2013 at 4:07 PM, Greg Kroah-Hartman
> wrote:
> > On Thu, Aug 29, 2013 at 02:27:52PM -0400, Alex Deucher wrote:
> >> On Thu, Aug 29, 2013 at 6:55 AM, Meelis Roos wrote:
> >> >> Reported-by: Meelis
[] ? set_page_attributes+0x11/0x12
[] ? load_module+0x12fa/0x17e8
[] ? map_vm_area+0x22/0x31
[] ? SyS_init_module+0x67/0x7d
[] ? sysenter_do_call+0x12/0x26
Reported-by: Meelis Roos
Signed-off-by: Sergey Senozhatsky
---
drivers/gpu/drm/radeon/radeon_irq_kms.c | 10 ++
1 file changed, 6
ks.
-ss
> a01c34f72e7cd2624570818f579b5ab464f93de2 is the first bad commit
> commit a01c34f72e7cd2624570818f579b5ab464f93de2
> Author: Sergey Senozhatsky
> Date: Sun Jul 14 14:03:27 2013 +0300
>
> radeon kms: do not flush uninitialized hotplug work
>
>
] ? set_page_attributes+0x11/0x12
[c104f6e1] ? load_module+0x12fa/0x17e8
[c107483b] ? map_vm_area+0x22/0x31
[c104fc36] ? SyS_init_module+0x67/0x7d
[c1234245] ? sysenter_do_call+0x12/0x26
Reported-by: Meelis Roos mr...@linux.ee
Signed-off-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
---
drivers/gpu/drm/radeon
...@linux.ee
Signed-off-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
It works, thank you for quick response!
Tested-by: Meelis Roos mr...@linux.ee
Thanks. I've added it to my patch queue.
Can you add a cc: stable mark if it also is going to affect the stable
kernels
s+0x120/0x330
[4.800909] [] kernel_init_freeable+0x111/0x191
[4.801052] [] ? do_early_param+0x88/0x88
[4.801233] [] ? rest_init+0x140/0x140
[4.801393] [] kernel_init+0xe/0x180
[4.801556] [] ret_from_fork+0x7c/0xb0
[4.801718] [] ? rest_init+0x140/0x140
Signed-off-by: Serge
-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
---
drivers/gpu/drm/radeon/radeon_irq_kms.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index bcdefd1..081886b 100644
--- a/drivers
1 - 100 of 110 matches
Mail list logo
