Hi John,
Sorry for no response on this, I have been away.
john stultz wrote:
quoted text > On Fri, 2009-12-18 at 19:20 -0800, Steven King wrote:
>> On Friday 18 December 2009 06:44:44 john stultz wrote:
>>> On Fri, Dec 18, 2009 at 6:13 PM, Steven King <sfking@fdwdc.com> wrote:
>>>> Attach is the .config; it works on v2.6.32 but fails to boot on .33-rc1;
>>>> but if I deselect hrtimers && tickless then it works.
>>> Sorry for the dup, forgot to cc lkml on my reply.
>>>
>>> Fails to boot all together? Or does it hang at some point in the dmesg
>>> that you can point out?
>> fails to boot all together; nothing on the serial console.
>>> Could you run the following so we can narrow down which clocksource your
>>> using? cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>>> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>>>
>>> Then with the kernel that doesn't boot, go through the clocksources
>>> listed in available_clocksources and try booting w/
>>> "clocksource=<clock name>" and see if the behavior changes.
>> on the working .32 kernel:
>>
>> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>> pit
>> # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>> pit
>>
>> just to be sure, I tried clocksource=pit on the .33-rc1 kernel. It didnt make
>> any difference.
>
>
> Hrmm.. So looking at the code in arch/m68knommu/platform/coldfire/pit.c,
> I'm a little confused on how this got marked as a continuous clocksource
> (CLOCK_SOURCE_IS_CONTINUOUS), especially as it seems it couldn't handle
> skipping an interrupt.
>
> That said, I'm not sure how it worked in 2.6.32, as its been that way
> for awhile it seems. Maybe my assumptions on how the PIT works is wrong
> (or just biased in how it works on x86)?
>
> Greg, could you clarify how the PIT can be used as a clocksource if its
> also being used in oneshot mode?
Looks broken. As Steven noted we just seem to have gotten away
with it, with no obvious breakage so far.
I see from follow-ons to this that Andrew has picked it up.
So I'll just ack that and let him push it.
Thanks
Greg
quoted text > Steven, I assume the patch below avoids the issue (by disabling highres
> timers and nohz)?
>
> thanks
> -john
>
>
>
> The m68knommu coldfire pit clocksource looks like it was incorrectly
> marked as a continuous clocksource. From the looks of it, running with
> it marked as a continuous clocksource could cause hangs when the system
> switches to highres mode or enables nohz. I have no idea why it worked
> in prior kernels, and I'm not 100% sure the following fix is really the
> right solution.
>
> This patch removes the CLOCK_SOURCE_IS_CONTINUOUS flag on the coldfire
> pit clocksource. This will disallow systems using this clocksource from
> entering oneshot mode (disabling highres timers and nohz).
>
> Signed-off-by: John Stultz <johnstul@us.ibm.com>
>
> ---
>
> diff --git a/arch/m68knommu/platform/coldfire/pit.c b/arch/m68knommu/platform/coldfire/pit.c
> index d8720ee..aebea19 100644
> --- a/arch/m68knommu/platform/coldfire/pit.c
> +++ b/arch/m68knommu/platform/coldfire/pit.c
> @@ -146,7 +146,6 @@ static struct clocksource pit_clk = {
> .read = pit_read_clk,
> .shift = 20,
> .mask = CLOCKSOURCE_MASK(32),
> - .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> };
>
> /***************************************************************************/
>
>
>
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL:
gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB:
http://www.SnapGear.com
--
unsubscribe notice To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/ Messages in current thread: 