All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] Lockdep splat on drm-tip
Date: Mon, 3 May 2021 14:39:41 +0200	[thread overview]
Message-ID: <cb0c621c-e3c1-ef85-e27a-2f90bb96be2e@linux.intel.com> (raw)
In-Reply-To: <c3625793-7271-58e9-f9a7-94862eccef20@linux.intel.com>

Op 03-05-2021 om 13:57 schreef Thomas Hellström:
> Hi, Maarten,
>
> I saw this the other day while working on the TTM conversion:
>
> 5925.509765] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:928
> [ 5925.509769] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 21608, name: kworker/2:1
> [ 5925.509772] INFO: lockdep is turned off.
> [ 5925.509775] irq event stamp: 0
> [ 5925.509777] hardirqs last  enabled at (0): [<0000000000000000>] 0x0
> [ 5925.509781] hardirqs last disabled at (0): [<ffffffff81073aa0>] copy_process+0x850/0x1c70
> [ 5925.509786] softirqs last  enabled at (0): [<ffffffff81073aa0>] copy_process+0x850/0x1c70
> [ 5925.509789] softirqs last disabled at (0): [<0000000000000000>] 0x0
> [ 5925.509792] Preemption disabled at:
> [ 5925.509793] [<ffffffff8107e2e3>] irq_enter_rcu+0x13/0x70
> [ 5925.509798] CPU: 2 PID: 21608 Comm: kworker/2:1 Tainted: G U  W         5.12.0-rc7-dmaresv-thellstr+ #3
> [ 5925.509803] Hardware name: Gigabyte Technology Co., Ltd. GB-Z390 Garuda/GB-Z390 Garuda-CF, BIOS IG1c 11/19/2019
> [ 5925.509807] Workqueue: events engine_retire [i915]
> [ 5925.509874] Call Trace:
> [ 5925.509876]  <IRQ>
> [ 5925.509878]  dump_stack+0x76/0x95
> [ 5925.509882]  ___might_sleep.cold+0xf2/0x103
> [ 5925.509887]  __might_sleep+0x4b/0x80
> [ 5925.509890]  __mutex_lock+0x5b/0x9b0
> [ 5925.509893]  ? lock_release+0x1ec/0x2b0
> [ 5925.509897]  ? debug_object_deactivate+0x137/0x160
> [ 5925.509902]  ? intel_context_post_unpin+0xb2/0x18c [i915]
> [ 5925.509960]  ? wake_up_var+0x37/0x40
> [ 5925.509964]  ? __active_retire+0x12f/0x210 [i915]
> [ 5925.510034]  mutex_lock_nested+0x1b/0x20
> [ 5925.510037]  ? i915_active_release+0x22/0x30 [i915]
> [ 5925.510105]  ? mutex_lock_nested+0x1b/0x20
> [ 5925.510108]  intel_context_post_unpin+0xb2/0x18c [i915]
> [ 5925.510166]  __intel_context_retire+0x26/0x74 [i915]
> [ 5925.510223]  __active_retire+0x11e/0x210 [i915]
> [ 5925.510291]  active_retire+0x2e/0x50 [i915]
> [ 5925.510357]  node_retire+0x23/0x30 [i915]
> [ 5925.510423]  signal_irq_work+0x318/0x6d0 [i915]
> [ 5925.510481]  irq_work_single+0x40/0x70
> [ 5925.510485]  irq_work_run_list+0x2a/0x40
> [ 5925.510488]  irq_work_run+0x2a/0x50
> [ 5925.510491]  __sysvec_irq_work+0x41/0x1b0
> [ 5925.510494]  sysvec_irq_work+0x93/0xb0
> [ 5925.510497]  </IRQ>
> [ 5925.510499]  asm_sysvec_irq_work+0x12/0x20
> [ 5925.510502] RIP: 0010:memchr_inv+0x44/0xd0
> [ 5925.510506] Code: 00 00 40 0f b6 ce 83 e8 01 49 b8 01 01 01 01 01 01 01 01 49 0f af c8 48 8d 44 c7 08 eb 09 48 83 c7 08 48 39 c7 74 64 48 3
> 9 0f <74> f2 48 8d 47 08 40 3a 37 75 7a 48 83 c7 01 48 39 f8 75 f2 31 c0
> [ 5925.510513] RSP: 0018:ffffc9000870fd68 EFLAGS: 00000246
> [ 5925.510516] RAX: ffffc90000bb7000 RBX: ffff88811f15e000 RCX: 5a5a5a5a5a5a5a5a
> [ 5925.510519] RDX: 0000000000001000 RSI: 000000000000005a RDI: ffffc90000bb61c0
> [ 5925.510522] RBP: ffffc9000870fd78 R08: 0101010101010101 R09: 0000000000000000
> [ 5925.510525] R10: ffff888105b15aec R11: 0000000000000018 R12: ffff88810980cd00
> [ 5925.510528] R13: ffff88811f15e078 R14: ffff88811f15e000 R15: ffff88811f15e000
> [ 5925.510534]  ? lrc_unpin+0x2f/0x50 [i915]
> [ 5925.510595]  intel_context_unpin+0x23/0xc0 [i915]
> [ 5925.510652]  i915_request_retire+0x21b/0x450 [i915]
> [ 5925.510722]  retire_requests+0x5b/0x80 [i915]
> [ 5925.510782]  engine_retire+0x68/0xa0 [i915]
> [ 5925.510841]  process_one_work+0x232/0x580
> [ 5925.510845]  worker_thread+0x50/0x3b0
> [ 5925.510849]  ? process_one_work+0x580/0x580
> [ 5925.510852]  kthread+0x143/0x180
> [ 5925.510854]  ? kthread_park+0x90/0x90
> [ 5925.510857]  ret_from_fork+0x1f/0x30
>
>
>
Weird backtrace, what's the mutex_lock_nested doing inside the interrupt, is the backtrace correct?

[ 5925.510037]  ? i915_active_release+0x22/0x30 [i915]
[ 5925.510105]  ? mutex_lock_nested+0x1b/0x20

Are you using PREEMPT_RT or something?


The backtrace doesn't seem to make sense as-is. I don't see mutexes being used inside unpin code. Maybe I'm missing something.

~Maarten

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

      reply	other threads:[~2021-05-03 12:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-03 11:57 [Intel-gfx] Lockdep splat on drm-tip Thomas Hellström
2021-05-03 12:39 ` Maarten Lankhorst [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cb0c621c-e3c1-ef85-e27a-2f90bb96be2e@linux.intel.com \
    --to=maarten.lankhorst@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=thomas.hellstrom@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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.