Messages in this thread | | | Date | Thu, 14 Jan 2010 19:43:50 +0800 | From | Xiaotian Feng <> | Subject | Re: [PATCH] clockevent: don't remove broadcast device when cpu is dead |
| |
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 >
| |