* [4.4-rc7 / vmwgfx] debugging bug or driver bug?
@ 2016-01-01 5:14 Tetsuo Handa
2016-01-01 10:31 ` Thomas Hellstrom
0 siblings, 1 reply; 3+ messages in thread
From: Tetsuo Handa @ 2016-01-01 5:14 UTC (permalink / raw)
To: thellstrom, syeh, charmainel, brianp; +Cc: dri-devel
I booted a CONFIG_PREEMPT_NONE=y && CONFIG_SMP=n kernel (linux.git as of
9c982e86dbdb), and hit BUG_ON() at __vmw_cmdbuf_header_free().
----------
static void __vmw_cmdbuf_header_free(struct vmw_cmdbuf_header *header)
{
struct vmw_cmdbuf_man *man = header->man;
BUG_ON(!spin_is_locked(&man->lock));
if (header->inline_space) {
vmw_cmdbuf_header_inline_free(header);
return;
}
(...snipped...)
----------
[ 1.883512] ------------[ cut here ]------------
[ 1.885102] kernel BUG at drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:250!
[ 1.886836] invalid opcode: 0000 [#1]
[ 1.888390] Modules linked in:
[ 1.889519] CPU: 0 PID: 59 Comm: kworker/0:2 Not tainted 4.4.0-rc7+ #22
[ 1.891125] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 1.893404] Workqueue: events vmw_fb_dirty_flush
[ 1.894767] task: ffff880036406e00 ti: ffff880079a98000 task.ti: ffff880079a98000
[ 1.896572] RIP: 0010:[<ffffffff8143dad4>] [<ffffffff8143dad4>] __vmw_cmdbuf_header_free.isra.16+0x4/0x10
[ 1.898729] RSP: 0018:ffff880079a9bae8 EFLAGS: 00010246
[ 1.900209] RAX: ffff8800365635c8 RBX: ffff88003654aa80 RCX: ffff8800365635e0
[ 1.901950] RDX: ffff8800365635e0 RSI: 0000000000000003 RDI: 0000000000000246
[ 1.903700] RBP: ffff880079a9bae8 R08: 0000000000000000 R09: 0000000000000000
[ 1.905713] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880079b1c300
[ 1.907498] R13: 0000000000000001 R14: ffff88003654aa98 R15: ffff880036563400
[ 1.909306] FS: 0000000000000000(0000) GS:ffffffff81c23000(0000) knlGS:0000000000000000
[ 1.911147] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.912711] CR2: 00007f8e571d8298 CR3: 0000000079b33000 CR4: 00000000001406f0
[ 1.914541] Stack:
[ 1.915430] ffff880079a9bb58 ffffffff8143dc78 ffff880036563430 ffff880036563490
[ 1.917350] ffff880036563478 ffff8800365635e0 ffff880036563590 ffff880036563458
[ 1.919311] ffff880036563468 ffff880036563400 ffff880079b1c300 0000000000000008
[ 1.921239] Call Trace:
[ 1.922235] [<ffffffff8143dc78>] vmw_cmdbuf_man_process+0xe8/0x220
[ 1.923841] [<ffffffff8143e20f>] __vmw_cmdbuf_cur_flush+0x8f/0xe0
[ 1.925504] [<ffffffff8143ea96>] vmw_cmdbuf_commit+0x96/0xe0
[ 1.927000] [<ffffffff814330c1>] vmw_fifo_commit_flush+0x21/0x40
[ 1.928559] [<ffffffff81433169>] vmw_fifo_send_fence+0x69/0xd0
[ 1.930145] [<ffffffff81426c90>] vmw_execbuf_fence_commands+0x50/0x100
[ 1.931767] [<ffffffff8142b4ab>] vmw_kms_helper_buffer_finish+0x4b/0xe0
[ 1.933442] [<ffffffff8143308e>] ? vmw_fifo_commit+0x1e/0x30
[ 1.935000] [<ffffffff81438139>] vmw_kms_sou_do_dmabuf_dirty+0xe9/0x110
[ 1.936652] [<ffffffff814374c0>] ? vmw_sou_surface_fifo_commit+0xf0/0xf0
[ 1.938408] [<ffffffff81437330>] ? vmw_sou_surface_clip+0x70/0x70
[ 1.939970] [<ffffffff81428b28>] vmw_framebuffer_dmabuf_dirty+0x148/0x1f0
[ 1.941589] [<ffffffff8107c5e9>] ? update_curr+0x99/0xe0
[ 1.943092] [<ffffffff8142df51>] vmw_fb_dirty_flush+0x231/0x290
[ 1.944586] [<ffffffff8106e1fb>] process_one_work+0x11b/0x310
[ 1.946087] [<ffffffff8106e4fe>] worker_thread+0x10e/0x440
[ 1.947586] [<ffffffff8164be9c>] ? __schedule+0x22c/0x590
[ 1.949067] [<ffffffff8106e3f0>] ? process_one_work+0x310/0x310
[ 1.950573] [<ffffffff810730f2>] kthread+0xd2/0xf0
[ 1.951894] [<ffffffff81073020>] ? kthread_worker_fn+0x150/0x150
[ 1.953472] [<ffffffff8164edff>] ret_from_fork+0x3f/0x70
[ 1.954905] [<ffffffff81073020>] ? kthread_worker_fn+0x150/0x150
[ 1.956432] Code: 48 8b 43 f0 c7 00 00 00 00 00 eb e2 be 5b 01 00 00 48 c7 c7 18 81 9a 81 e8 4a d6 c1 ff c6 05 d8 e1 86 00 01 eb da 90 55 48 89 e5 <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 54 53 48 89
[ 1.962434] RIP [<ffffffff8143dad4>] __vmw_cmdbuf_header_free.isra.16+0x4/0x10
[ 1.964217] RSP <ffff880079a9bae8>
[ 1.965409] ---[ end trace 6120f678d5112bae ]---
[ 1.966727] Kernel panic - not syncing: Fatal exception in interrupt
[ 1.968374] Kernel Offset: disabled
[ 1.969467] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [4.4-rc7 / vmwgfx] debugging bug or driver bug?
2016-01-01 5:14 [4.4-rc7 / vmwgfx] debugging bug or driver bug? Tetsuo Handa
@ 2016-01-01 10:31 ` Thomas Hellstrom
2016-01-01 14:04 ` Tetsuo Handa
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Hellstrom @ 2016-01-01 10:31 UTC (permalink / raw)
To: Tetsuo Handa, syeh, charmainel, brianp; +Cc: dri-devel
Thanks for reporting.
Hmm,
Most likely the spin_is_locked() function is not working on non - SMP
systems (well how could it?). An oversight from my side.
We should change the BUG_ON line to a lockdep_assert_held().
I'll try to get a patch out today.
On 01/01/2016 06:14 AM, Tetsuo Handa wrote:
> I booted a CONFIG_PREEMPT_NONE=y && CONFIG_SMP=n kernel (linux.git as of
> 9c982e86dbdb), and hit BUG_ON() at __vmw_cmdbuf_header_free().
>
> ----------
> static void __vmw_cmdbuf_header_free(struct vmw_cmdbuf_header *header)
> {
> struct vmw_cmdbuf_man *man = header->man;
>
> BUG_ON(!spin_is_locked(&man->lock));
>
> if (header->inline_space) {
> vmw_cmdbuf_header_inline_free(header);
> return;
> }
> (...snipped...)
> ----------
>
> [ 1.883512] ------------[ cut here ]------------
> [ 1.885102] kernel BUG at drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:250!
> [ 1.886836] invalid opcode: 0000 [#1]
> [ 1.888390] Modules linked in:
> [ 1.889519] CPU: 0 PID: 59 Comm: kworker/0:2 Not tainted 4.4.0-rc7+ #22
> [ 1.891125] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
> [ 1.893404] Workqueue: events vmw_fb_dirty_flush
> [ 1.894767] task: ffff880036406e00 ti: ffff880079a98000 task.ti: ffff880079a98000
> [ 1.896572] RIP: 0010:[<ffffffff8143dad4>] [<ffffffff8143dad4>] __vmw_cmdbuf_header_free.isra.16+0x4/0x10
> [ 1.898729] RSP: 0018:ffff880079a9bae8 EFLAGS: 00010246
> [ 1.900209] RAX: ffff8800365635c8 RBX: ffff88003654aa80 RCX: ffff8800365635e0
> [ 1.901950] RDX: ffff8800365635e0 RSI: 0000000000000003 RDI: 0000000000000246
> [ 1.903700] RBP: ffff880079a9bae8 R08: 0000000000000000 R09: 0000000000000000
> [ 1.905713] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880079b1c300
> [ 1.907498] R13: 0000000000000001 R14: ffff88003654aa98 R15: ffff880036563400
> [ 1.909306] FS: 0000000000000000(0000) GS:ffffffff81c23000(0000) knlGS:0000000000000000
> [ 1.911147] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1.912711] CR2: 00007f8e571d8298 CR3: 0000000079b33000 CR4: 00000000001406f0
> [ 1.914541] Stack:
> [ 1.915430] ffff880079a9bb58 ffffffff8143dc78 ffff880036563430 ffff880036563490
> [ 1.917350] ffff880036563478 ffff8800365635e0 ffff880036563590 ffff880036563458
> [ 1.919311] ffff880036563468 ffff880036563400 ffff880079b1c300 0000000000000008
> [ 1.921239] Call Trace:
> [ 1.922235] [<ffffffff8143dc78>] vmw_cmdbuf_man_process+0xe8/0x220
> [ 1.923841] [<ffffffff8143e20f>] __vmw_cmdbuf_cur_flush+0x8f/0xe0
> [ 1.925504] [<ffffffff8143ea96>] vmw_cmdbuf_commit+0x96/0xe0
> [ 1.927000] [<ffffffff814330c1>] vmw_fifo_commit_flush+0x21/0x40
> [ 1.928559] [<ffffffff81433169>] vmw_fifo_send_fence+0x69/0xd0
> [ 1.930145] [<ffffffff81426c90>] vmw_execbuf_fence_commands+0x50/0x100
> [ 1.931767] [<ffffffff8142b4ab>] vmw_kms_helper_buffer_finish+0x4b/0xe0
> [ 1.933442] [<ffffffff8143308e>] ? vmw_fifo_commit+0x1e/0x30
> [ 1.935000] [<ffffffff81438139>] vmw_kms_sou_do_dmabuf_dirty+0xe9/0x110
> [ 1.936652] [<ffffffff814374c0>] ? vmw_sou_surface_fifo_commit+0xf0/0xf0
> [ 1.938408] [<ffffffff81437330>] ? vmw_sou_surface_clip+0x70/0x70
> [ 1.939970] [<ffffffff81428b28>] vmw_framebuffer_dmabuf_dirty+0x148/0x1f0
> [ 1.941589] [<ffffffff8107c5e9>] ? update_curr+0x99/0xe0
> [ 1.943092] [<ffffffff8142df51>] vmw_fb_dirty_flush+0x231/0x290
> [ 1.944586] [<ffffffff8106e1fb>] process_one_work+0x11b/0x310
> [ 1.946087] [<ffffffff8106e4fe>] worker_thread+0x10e/0x440
> [ 1.947586] [<ffffffff8164be9c>] ? __schedule+0x22c/0x590
> [ 1.949067] [<ffffffff8106e3f0>] ? process_one_work+0x310/0x310
> [ 1.950573] [<ffffffff810730f2>] kthread+0xd2/0xf0
> [ 1.951894] [<ffffffff81073020>] ? kthread_worker_fn+0x150/0x150
> [ 1.953472] [<ffffffff8164edff>] ret_from_fork+0x3f/0x70
> [ 1.954905] [<ffffffff81073020>] ? kthread_worker_fn+0x150/0x150
> [ 1.956432] Code: 48 8b 43 f0 c7 00 00 00 00 00 eb e2 be 5b 01 00 00 48 c7 c7 18 81 9a 81 e8 4a d6 c1 ff c6 05 d8 e1 86 00 01 eb da 90 55 48 89 e5 <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 54 53 48 89
> [ 1.962434] RIP [<ffffffff8143dad4>] __vmw_cmdbuf_header_free.isra.16+0x4/0x10
> [ 1.964217] RSP <ffff880079a9bae8>
> [ 1.965409] ---[ end trace 6120f678d5112bae ]---
> [ 1.966727] Kernel panic - not syncing: Fatal exception in interrupt
> [ 1.968374] Kernel Offset: disabled
> [ 1.969467] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [4.4-rc7 / vmwgfx] debugging bug or driver bug?
2016-01-01 10:31 ` Thomas Hellstrom
@ 2016-01-01 14:04 ` Tetsuo Handa
0 siblings, 0 replies; 3+ messages in thread
From: Tetsuo Handa @ 2016-01-01 14:04 UTC (permalink / raw)
To: thellstrom, syeh, charmainel, brianp; +Cc: dri-devel
Thomas Hellstrom wrote:
> Most likely the spin_is_locked() function is not working on non - SMP
> systems (well how could it?). An oversight from my side.
You are right. I found a description in Documentation/scsi/ChangeLog.megaraid .
there are several checks present in the kernel
where somebody does a variation on the following:
BUG_ON(!spin_is_locked(&some_lock));
so what's wrong about that? nothing, unless you
compile the code with CONFIG_DEBUG_SPINLOCK but
without CONFIG_SMP ... in which case the BUG()
will kill your kernel ...
> We should change the BUG_ON line to a lockdep_assert_held().
static __always_inline int spin_is_locked(spinlock_t *lock)
{
return raw_spin_is_locked(&lock->rlock);
}
#define raw_spin_is_locked(lock) arch_spin_is_locked(&(lock)->raw_lock)
include/linux/spinlock_up.h: /* !DEBUG_SPINLOCK */
#define arch_spin_is_locked(lock) ((void)(lock), 0)
So, BUG_ON(!spin_is_locked(&man->lock)) was BUG_ON(!0) in my config, and
below change fixed this problem.
Regards.
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
index 6377e81..4d26de4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
@@ -247,7 +247,7 @@ static void __vmw_cmdbuf_header_free(struct vmw_cmdbuf_header *header)
{
struct vmw_cmdbuf_man *man = header->man;
- BUG_ON(!spin_is_locked(&man->lock));
+ lockdep_assert_held(&man->lock);
if (header->inline_space) {
vmw_cmdbuf_header_inline_free(header);
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-01-01 14:04 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-01-01 5:14 [4.4-rc7 / vmwgfx] debugging bug or driver bug? Tetsuo Handa
2016-01-01 10:31 ` Thomas Hellstrom
2016-01-01 14:04 ` Tetsuo Handa
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.