From: Xiaotian Feng <dfeng@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org, Magnus Damm <damm@igel.co.jp>,
H Hartley Sweeten <hsweeten@visionengravers.com>
Subject: Re: [PATCH] clockevent: don't remove broadcast device when cpu is dead
Date: Thu, 14 Jan 2010 19:43:50 +0800 [thread overview]
Message-ID: <4B4F0376.3090906@redhat.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1001132305280.6420@localhost.localdomain>
On 01/14/2010 06:08 AM, Thomas Gleixner wrote:
> On Wed, 13 Jan 2010, Xiaotian Feng wrote:
>> On 01/12/2010 09:20 PM, Thomas Gleixner wrote:
>>> On Thu, 7 Jan 2010, Xiaotian Feng wrote:
>>>
>>>> Marc reported BUG during shutdown, after debugging, kernel is trying
>>>> to remove a broadcast device which mode is CLOCK_EVT_MODE_ONESHOT.
>>>>
>>>> The root cause for this bug is that in clockevents_notify,
>>>> "cpumask_weight(dev->cpumask) == 1" is always true even if dev is a
>>>
>>> Why is cpumask_weight(dev->cpumask) == 1 always true when we shutdown
>>> a non boot cpu ?
>>>
>>> The broadcast device is not a per cpu device and the cpumask should
>>> not only contain the CPU which is shut down !
>>
>> At least for hpet broadcast dev, it's dev->cpumask is only contain the CPU
>> which it is initialized from.
>
> Which is fundamentaly wrong and the root cause of the problem. I'll
> have a look tomorrow morning when my brain is more awake than now.
hpet_legacy_clockevent_register is trying to register new CE, but
replace failed,
then in tick_check_new_device -> tick_check_broadcast_device, the legacy
hpet CE
was registered as multicast device, but its dev->cpumask is cpumask of
smp_processor_id().
on my system its dev->cpumask is cpumask of 0, but in Marc's,
dev->cpumask is cpumask of 4.
So when kernel is trying to offline cpu 4, the broadcast hpet is removed.
>
>> And for broadcast device, kernel is using tick_broadcast_mask not
>> dev->cpumask, right?
>
> No, tick_broadcast_mask is the bitmask which tells us which cpus get
> the broadcast IPI.
>
> Thanks,
>
> tglx
>
next prev parent reply other threads:[~2010-01-14 11:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-07 3:22 [PATCH] clockevent: don't remove broadcast device when cpu is dead Xiaotian Feng
2010-01-12 2:24 ` Xiaotian Feng
2010-01-12 13:20 ` Thomas Gleixner
2010-01-13 1:28 ` Marc Dionne
2010-01-13 1:48 ` Xiaotian Feng
2010-01-13 22:08 ` Thomas Gleixner
2010-01-14 11:43 ` Xiaotian Feng [this message]
2010-01-14 11:52 ` Thomas Gleixner
2010-01-18 13:48 ` [tip:timers/urgent] clockevent: Don't " tip-bot for Xiaotian Feng
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=4B4F0376.3090906@redhat.com \
--to=dfeng@redhat.com \
--cc=damm@igel.co.jp \
--cc=hsweeten@visionengravers.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/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.