Date:	Mon, 01 Jul 2013 12:50:05 -0700
From:	Stephen Boyd <sboyd@...eaurora.org>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Stehle Vincent-B46079 <B46079@...escale.com>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mark Rutland <mark.rutland@....com>
Subject: Re: next-20130627 breaks i.MX6 sabre sd UART console

On 07/01/13 10:49, Thomas Gleixner wrote:
> On Mon, 1 Jul 2013, Stehle Vincent-B46079 wrote:
>
>> From: Thomas Gleixner [mailto:tglx@...utronix.de] 
>>> (..) Can you please apply the patch below and provide the output?
>> Sure; thanks for the patch. The kernel seems to be in a loop, as it prints many messages and never stops. I copy only the first ones:
>>
>> ...
>> Switched to clocksource mxc_timer1
>> next 800000000098967f nevt 7fffffffffffffff per 989680 nxtp 1c03a180 now 1c553a59
> Yuck. nevt (dev->next_event) is KTIME_MAX. No surprise, that we end up
> in an endless loop.
>
> Now the question is how we did end up with that and how is that
> related to the dummy timer.
>
> From your debug output we see that the dummy timer is installed before
> the local timer. The dummytimer is disfunctional, so it requires
> broadcast in the first place.
>
> Now when we install the local timer the broadcast is not disabled,
> because the local timer is affected by C3STOP. Now the CPU is not in a
> power state which makes the broadcasting necessary, but the broadcast
> code has no way to distinguish whether the broadcast bit is set due to
> power state or due to a dummy timer.
>
> That's clearly wrong as we end up with two periodic events for that
> cpu (broadcast and local timer) as long as nothing calls into the
> broadcast control code. That's fixable with some surgery.

Yes, that sounds like the problem. Before this change the dummy would
never have been installed first and so the broadcast timer wouldn't be
running during boot.

>
> Though that does not explain why dev->next_event is set to KTIME_MAX
> after we installed the mxc_timer1 as the system clocksource. And we
> really need to know why that happens. 
>
> Here is some more debugging which should shine some light on that.

Each local_timer clockevent should have their next_event set for
KTIME_MAX when they're registered because they get "shutdown" initially.
twd timers support both periodic and oneshot, so we won't emulate
periodic mode with oneshot mode. Looking at tick_setup_periodic() it
looks like the next_event member is ignored and we just set the mode to
periodic. KTIME_MAX should still be there. That should be fine though as
long as we don't switch the tick device into oneshot mode.

It seems that someone is switching the tick device into oneshot mode
without changing the event handler away from tick_handle_periodic(). Is
that supposed to happen? Most clockevents_set_mode(ONESHOT) calls are
prefaced with a handler change or they're operating on the broadcast
device. I suspect that tick_check_oneshot_broadcast() is the bad one.
That one changes the mode and then tick_handle_periodic() probably runs
past that if check and starts trying to emulate periodic mode when
next_event is still KTIME_MAX.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

Powered by blists - more mailing lists