[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXxSxUHGN99hXK8K5k9ayVfMenAWAbWVpqkotix_JyUbPCU+w@mail.gmail.com>
Date: Mon, 31 Oct 2011 18:48:45 +0800
From: Chen Jie <chenj@...ote.com>
To: Yong Zhang <yong.zhang0@...il.com>
Cc: linux-mips@...ux-mips.org, LKML <linux-kernel@...r.kernel.org>,
johnstul@...ibm.com, tglx@...utronix.de, yanhua <yanh@...ote.com>,
项宇 <xiangy@...ote.com>,
zhangfx <zhangfx@...ote.com>,
孙海勇 <sunhy@...ote.com>
Subject: Re: [MIPS]clocks_calc_mult_shift() may gen a too big mult value
Hi,
2011/10/31 Yong Zhang <yong.zhang0@...il.com>:
> On Mon, Oct 31, 2011 at 5:00 PM, Chen Jie <chenj@...ote.com> wrote:
>> Hi all,
>>
>> On MIPS, with maxsec=4, clocks_calc_mult_shift() may generate a very
>> big mult, which may easily cause timekeeper.mult overflow within
>> timekeeping jobs.
>
> Hmmm, why not use clocksource_register_hz()/clocksource_register_khz()
> instead? it's more convenient.
Thanks for the suggestion. And sorry for I didn't notice the upstream
code has already hooked to clocksource_register_hz() in csrc-r4k.c
(We're using r4000 clock source)
I'm afraid this still doesn't fix my case. Through
clocksource_register_hz()->__clocksource_register_scale()->__clocksource_updatefreq_scale,
I got a calculated maxsec = (0xffffffff - (0xffffffff>>5))/250000500 =
16 # assume mips_hpt_frequency=250000500
With this maxsec, I got a mult of 0xffffde72, still too big.
Regards,
-- Chen Jie
--
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