On Fri, 5 Jul 2013, Shinya Kuribayashi wrote:
> On 6/28/2013 9:22 PM, Thomas Gleixner wrote:
> >> On the other hand, we have another call site of tick_program_event() at
> >> the bottom of hrtimer_interrupt(). The warning this time is triggered
> >> there, so we need to apply the same fix to it.
>
On 6/28/2013 9:22 PM, Thomas Gleixner wrote:
>> On the other hand, we have another call site of tick_program_event() at
>> the bottom of hrtimer_interrupt(). The warning this time is triggered
>> there, so we need to apply the same fix to it.
>
> Well, the problem is that you are just papering ov
On Tue, 11 Jun 2013, Shinya Kuribayashi wrote:
> When executing a date command to set the system date and time to a few
> seconds before the 2038 problem expiration time, we got a WARN_ON_ONCE()
> like this:
>
> root@renesas:~# date -s "2038-1-19 3:14:00"
> Tue Jan 19 03:14:00 GMT 2038
> (t
Hello,
On 6/12/2013 9:21 PM, Prarit Bhargava wrote:
> On 06/11/2013 03:41 AM, Shinya Kuribayashi wrote:
>> [ 27.857330] hrtimer: interrupt took 0 ns
>
> ^^^ see below ...
This may be because the frequency of our tick timer source in this
system is very slow, it's 32768 Hz. I think it's not
On 06/11/2013 03:41 AM, Shinya Kuribayashi wrote:
> When executing a date command to set the system date and time to a few
> seconds before the 2038 problem expiration time, we got a WARN_ON_ONCE()
> like this:
>
> root@renesas:~# date -s "2038-1-19 3:14:00"
> Tue Jan 19 03:14:00 GMT 2038
>
When executing a date command to set the system date and time to a few
seconds before the 2038 problem expiration time, we got a WARN_ON_ONCE()
like this:
root@renesas:~# date -s "2038-1-19 3:14:00"
Tue Jan 19 03:14:00 GMT 2038
(then wait for 7-8 seconds)
root@renesas:~# [ 27.662658] ---
6 matches
Mail list logo