Re: [PATCH] clockevent: don't remove broadcast device when cpu isdead

From: Xiaotian Feng
Date: Thu Jan 14 2010 - 06:44:53 EST


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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/