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
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 over the
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.
Well,
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
>
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
(then wait
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
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
>
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
(then
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]
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]
12 matches
Mail list logo
