From: Ingo Molnar <mingo@kernel.org>
To: Chris J Arges <chris.j.arges@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Rafael David Tinoco <inaddy@ubuntu.com>,
Peter Anvin <hpa@zytor.com>,
Jiang Liu <jiang.liu@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
LKML <linux-kernel@vger.kernel.org>, Jens Axboe <axboe@kernel.dk>,
Frederic Weisbecker <fweisbec@gmail.com>,
Gema Gomez <gema.gomez-solano@canonical.com>,
the arch/x86 maintainers <x86@kernel.org>
Subject: Re: [debug PATCHes] Re: smp_call_function_single lockups
Date: Wed, 1 Apr 2015 14:39:13 +0200 [thread overview]
Message-ID: <20150401123913.GA12841@gmail.com> (raw)
In-Reply-To: <20150331223800.GB12512@canonical.com>
* Chris J Arges <chris.j.arges@canonical.com> wrote:
> This was only tested only on the L1, so I can put this on the L0 host and run
> this as well. The results:
>
> [ 124.897002] apic: vector c1, new-domain move in progress
> [ 124.954827] apic: vector d1, sent cleanup vector, move completed
> [ 163.477270] apic: vector d1, new-domain move in progress
> [ 164.041938] apic: vector e1, sent cleanup vector, move completed
> [ 213.466971] apic: vector e1, new-domain move in progress
> [ 213.775639] apic: vector 22, sent cleanup vector, move completed
> [ 365.996747] apic: vector 22, new-domain move in progress
> [ 366.011136] apic: vector 42, sent cleanup vector, move completed
> [ 393.836032] apic: vector 42, new-domain move in progress
> [ 393.837727] apic: vector 52, sent cleanup vector, move completed
> [ 454.977514] apic: vector 52, new-domain move in progress
> [ 454.978880] apic: vector 62, sent cleanup vector, move completed
> [ 467.055730] apic: vector 62, new-domain move in progress
> [ 467.058129] apic: vector 72, sent cleanup vector, move completed
> [ 545.280125] apic: vector 72, new-domain move in progress
> [ 545.282801] apic: vector 82, sent cleanup vector, move completed
> [ 567.631652] apic: vector 82, new-domain move in progress
> [ 567.632207] apic: vector 92, sent cleanup vector, move completed
> [ 628.940638] apic: vector 92, new-domain move in progress
> [ 628.965274] apic: vector a2, sent cleanup vector, move completed
> [ 635.187433] apic: vector a2, new-domain move in progress
> [ 635.191643] apic: vector b2, sent cleanup vector, move completed
> [ 673.548020] apic: vector b2, new-domain move in progress
> [ 673.553843] apic: vector c2, sent cleanup vector, move completed
> [ 688.221906] apic: vector c2, new-domain move in progress
> [ 688.229487] apic: vector d2, sent cleanup vector, move completed
> [ 723.818916] apic: vector d2, new-domain move in progress
> [ 723.828970] apic: vector e2, sent cleanup vector, move completed
> [ 733.485435] apic: vector e2, new-domain move in progress
> [ 733.615007] apic: vector 23, sent cleanup vector, move completed
> [ 824.092036] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ksmd:26]
Are these all the messages? Looks like Linus's warnings went away, or
did you filter them out?
But ... the affinity setting message does not appear to trigger, and
that's the only real race I can see in the code. Also, the frequency
of these messages appears to be low, while the race window is narrow.
So I'm not sure the problem is related to the irq-move mechanism.
One thing that appears to be weird: why is there irq-movement activity
to begin with? Is something changing irq-affinities?
Could you put a dump_stack() into the call? Something like the patch
below, in addition to all patches so far. (if it conflicts with the
previous debugging patches then just add the code manually to after
the debug printout.)
Thanks,
Ingo
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 6cedd7914581..79d6de6fdf0a 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -144,6 +144,8 @@ __assign_irq_vector(int irq, struct irq_cfg *cfg, const struct cpumask *mask)
cfg->move_in_progress =
cpumask_intersects(cfg->old_domain, cpu_online_mask);
cpumask_and(cfg->domain, cfg->domain, tmp_mask);
+ if (cfg->move_in_progress)
+ dump_stack();
break;
}
next prev parent reply other threads:[~2015-04-01 12:39 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-11 13:19 smp_call_function_single lockups Rafael David Tinoco
2015-02-11 18:18 ` Linus Torvalds
2015-02-11 19:59 ` Linus Torvalds
2015-02-11 20:42 ` Linus Torvalds
2015-02-12 16:38 ` Rafael David Tinoco
2015-02-18 22:25 ` Peter Zijlstra
2015-02-19 15:42 ` Rafael David Tinoco
2015-02-19 16:14 ` Linus Torvalds
2015-02-23 14:01 ` Rafael David Tinoco
2015-02-23 19:32 ` Linus Torvalds
2015-02-23 20:50 ` Peter Zijlstra
2015-02-23 21:02 ` Rafael David Tinoco
2015-02-19 16:16 ` Peter Zijlstra
2015-02-19 16:26 ` Linus Torvalds
2015-02-19 16:32 ` Rafael David Tinoco
2015-02-19 16:59 ` Linus Torvalds
2015-02-19 17:30 ` Rafael David Tinoco
2015-02-19 17:39 ` Linus Torvalds
2015-02-19 20:29 ` Linus Torvalds
2015-02-19 21:59 ` Linus Torvalds
2015-02-19 22:45 ` Linus Torvalds
2015-03-31 3:15 ` Chris J Arges
2015-03-31 4:28 ` Linus Torvalds
2015-03-31 10:56 ` [debug PATCHes] " Ingo Molnar
2015-03-31 22:38 ` Chris J Arges
2015-04-01 12:39 ` Ingo Molnar [this message]
2015-04-01 14:10 ` Chris J Arges
2015-04-01 14:55 ` Ingo Molnar
2015-03-31 4:46 ` Linus Torvalds
2015-03-31 15:08 ` Linus Torvalds
2015-03-31 22:23 ` Chris J Arges
2015-03-31 23:07 ` Linus Torvalds
2015-04-01 14:32 ` Chris J Arges
2015-04-01 15:36 ` Linus Torvalds
2015-04-02 9:55 ` Ingo Molnar
2015-04-02 17:35 ` Linus Torvalds
2015-04-01 12:43 ` Ingo Molnar
2015-04-01 16:10 ` Chris J Arges
2015-04-01 16:14 ` Linus Torvalds
2015-04-01 21:59 ` Chris J Arges
2015-04-02 17:31 ` Linus Torvalds
2015-04-02 18:26 ` Ingo Molnar
2015-04-02 18:51 ` Chris J Arges
2015-04-02 19:07 ` Ingo Molnar
2015-04-02 20:57 ` Linus Torvalds
2015-04-02 21:13 ` Chris J Arges
2015-04-03 5:43 ` [PATCH] smp/call: Detect stuck CSD locks Ingo Molnar
2015-04-03 5:47 ` Ingo Molnar
2015-04-06 16:58 ` Chris J Arges
2015-04-06 17:32 ` Linus Torvalds
2015-04-07 9:21 ` Ingo Molnar
2015-04-07 20:59 ` Chris J Arges
2015-04-07 21:15 ` Linus Torvalds
2015-04-08 6:47 ` Ingo Molnar
2015-04-13 3:56 ` Chris J Arges
2015-04-13 6:14 ` Ingo Molnar
2015-04-15 19:54 ` Chris J Arges
2015-04-16 11:04 ` Ingo Molnar
2015-04-16 15:58 ` Chris J Arges
2015-04-16 16:31 ` Ingo Molnar
2015-04-29 21:08 ` Chris J Arges
2015-05-11 14:00 ` Ingo Molnar
2015-05-20 18:19 ` Chris J Arges
2015-04-03 5:45 ` smp_call_function_single lockups Ingo Molnar
2015-04-06 17:23 ` Chris J Arges
2015-02-20 9:30 ` Ingo Molnar
2015-02-20 16:49 ` Linus Torvalds
2015-02-20 19:41 ` Ingo Molnar
2015-02-20 20:03 ` Linus Torvalds
2015-02-20 20:11 ` Ingo Molnar
2015-03-20 10:15 ` Peter Zijlstra
2015-03-20 16:26 ` Linus Torvalds
2015-03-20 17:14 ` Mike Galbraith
2015-04-01 14:22 ` Frederic Weisbecker
2015-04-18 10:13 ` [tip:locking/urgent] smp: Fix smp_call_function_single_async() locking tip-bot for Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2015-04-01 2:00 [debug PATCHes] Re: smp_call_function_single lockups Daniel J Blueman
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=20150401123913.GA12841@gmail.com \
--to=mingo@kernel.org \
--cc=axboe@kernel.dk \
--cc=chris.j.arges@canonical.com \
--cc=fweisbec@gmail.com \
--cc=gema.gomez-solano@canonical.com \
--cc=hpa@zytor.com \
--cc=inaddy@ubuntu.com \
--cc=jiang.liu@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).