Re: Crash in RTC

Re: Crash in RTC

[Konstantin Kostiuk]

[-- Attachment #1: Type: text/plain, Size: 2591 bytes --]

ping

On Wed, Aug 31, 2022 at 11:33 AM Vadim Rozenfeld <vrozenfe@redhat.com>
wrote:

> Just a bit more info related to this issue.
> Below is a quote from my previous conversation with Yan
>
> </QUOTE>
> QEMU RTC function periodic_timer_update is calling in response
> to Windows HAL calls
> _HalpRtcArmTimer@16
> and
> _HalpRtcStop@4
>
> WIndows can change timer  frequency  dynamically
> (some more info can be found here
> https://bugzilla.redhat.com/show_bug.cgi?id=1610461 )
> but calculation of the frequency is based on the wallclock time (IIRC).
> And if I'm not mistaken, then lost_tick_policy=delay can lead to the
> wallclock time delay,
> which in my understanding can lead to the incorrect frequency calculation.
>
> Another interesting thing is that they don't use Hyper-V enlightenments at
> all.
> Do you know if there is any particular reason for that?  They might try
> switching
> to hv_stimer instead of RTC.
>
> And one more thing, the frequency of the timer can be adjusted by UM
> applications.
> Some of them , like emulators and servers use it quite widely. It worse
> asking them
> if they are running such kinds of apps.
> </QUOTE>
>
>
> Cheers,
> Vadim.
>
> On Wed, Aug 31, 2022 at 5:46 PM Konstantin Kostiuk <kkostiuk@redhat.com>
> wrote:
>
>> CC: Vadim
>>
>> On Wed, Aug 31, 2022 at 10:42 AM Konstantin Kostiuk <kkostiuk@redhat.com>
>> wrote:
>>
>>> ping
>>>
>>> On Wed, Aug 24, 2022 at 5:37 PM Konstantin Kostiuk <kkostiuk@redhat.com>
>>> wrote:
>>>
>>>> Hi Michael and Paolo,
>>>>
>>>> I write to you as maintainers of mc146818rtc.c. I am working on bug
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=2054781
>>>> and reproduced it on the current master branch.
>>>>
>>>> I added some print at line 202 (before assert(lost_clock >= 0),
>>>> https://gitlab.com/qemu-project/qemu/-/blob/master/hw/rtc/mc146818rtc.c#L202)
>>>> and got the following values:
>>>>
>>>> next_periodic_clock, old_period, last_periodic_clock, cur_clock,
>>>> lost_clock, current_time
>>>> 54439076429968, 32, 54439076429936, 54439076430178, 242,
>>>> 1661348768010822000
>>>> 54439076430224, 512, 54439076429712, 54439076430188, 476,
>>>> 1661348768011117000
>>>> 54439076430224, 32, 54439076430192, 54439076429884, -308,
>>>> 1661348768001838000
>>>>
>>>> The current_time value in the last print is lower than in the previous
>>>> one.
>>>> So, the error occurs because time has gone backward.
>>>>
>>>> I think this is a possible situation during time synchronization.
>>>> My question is what should we do in this case?
>>>>
>>>> Best Regards,
>>>> Konstantin Kostiuk.
>>>>
>>>

[-- Attachment #2: Type: text/html, Size: 4328 bytes --]

Re: Crash in RTC

[Konstantin Kostiuk]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

ping

On Wed, Aug 24, 2022 at 5:37 PM Konstantin Kostiuk <kkostiuk@redhat.com>
wrote:

> Hi Michael and Paolo,
>
> I write to you as maintainers of mc146818rtc.c. I am working on bug
> https://bugzilla.redhat.com/show_bug.cgi?id=2054781
> and reproduced it on the current master branch.
>
> I added some print at line 202 (before assert(lost_clock >= 0),
> https://gitlab.com/qemu-project/qemu/-/blob/master/hw/rtc/mc146818rtc.c#L202)
> and got the following values:
>
> next_periodic_clock, old_period, last_periodic_clock, cur_clock,
> lost_clock, current_time
> 54439076429968, 32, 54439076429936, 54439076430178, 242,
> 1661348768010822000
> 54439076430224, 512, 54439076429712, 54439076430188, 476,
> 1661348768011117000
> 54439076430224, 32, 54439076430192, 54439076429884, -308,
> 1661348768001838000
>
> The current_time value in the last print is lower than in the previous one.
> So, the error occurs because time has gone backward.
>
> I think this is a possible situation during time synchronization.
> My question is what should we do in this case?
>
> Best Regards,
> Konstantin Kostiuk.
>

[-- Attachment #2: Type: text/html, Size: 1690 bytes --]