Re: clockevents_program_event WARN_ON preventing boot.

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, 2 May 2013, Yinghai Lu wrote:
> On Thu, May 2, 2013 at 2:19 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > Can you please apply the following debug patch and provide the output?
> >
> > diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
> > index c6d6400..b4d9622 100644
> > --- a/kernel/time/clockevents.c
> > +++ b/kernel/time/clockevents.c
> > @@ -207,6 +207,8 @@ int clockevents_program_event(struct clock_event_device *dev, ktime_t expires,
> >
> >         if (unlikely(expires.tv64 < 0)) {
> >                 WARN_ON_ONCE(1);
> > +               printk_once(KERN_INFO "expires %llx, dev->next %llx\n",
> > +                           expires.tv64, dev->next_event.tv64);

> [    3.454628] expires 80000000003d08ff, dev->next 7fffffffffffffff

So dev->next_event == KTIME_MAX. That means that the device has been
shut down, at least I can't see any other reason at that point - we
are not in highres/nohz mode yet. And it still got an interrupt served
for whatever reason. What's even more confusing is that in
tick_handle_periodic() we check for:

        if (dev->mode != CLOCK_EVT_MODE_ONESHOT)
                return;

So if the device is shutdown for real the mode would be
CLOCK_EVT_MODE_SHUTDOWN and we'd never reach that code.

Shut down at that point only happens in context of the broadcast
crap. Your crash:

[   10.272017] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000048
[   10.289803] IP: [<ffffffff810e3c46>] tick_do_broadcast+0x86/0xa0

points to the broadcast stuff as well. 0x48 is the offset of the
broadcast function. So your machine died at:

                td->evtdev->broadcast(mask);

That means, that the cpu was set in the broadcast mask, but the per
cpu event device was not yet registered !?!

That does not make any sense, as we explicitely prevent the broadcast
activation for cpus which have no per cpu tick device registered yet.

I'm fundamentally confused and Daves observation about slub debug does
not make it less confusing.

It'd be nice if you could add some more instrumentation or bisect the
issue.

Thanks,

	tglx