Messages in this thread | | | Date | Thu, 14 Jan 2010 12:52:38 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [PATCH] clockevent: don't remove broadcast device when cpu is dead |
| |
On Thu, 14 Jan 2010, Xiaotian Feng wrote: > 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.
I know, but the point is that a broadcast device should not be bound to the CPU which is registering it. Working on a fix.
Thanks,
tglx
| |