* Re: Crash in RTC
[not found] ` <CAKiOO4unENQQHp7w7MUUdTStyBS7ZFi8wFKWtpe10_GGqg1URQ@mail.gmail.com>
@ 2022-10-27 7:49 ` Konstantin Kostiuk
0 siblings, 0 replies; 2+ messages in thread
From: Konstantin Kostiuk @ 2022-10-27 7:49 UTC (permalink / raw)
To: Paolo Bonzini, Michael S. Tsirkin; +Cc: Vadim Rozenfeld, QEMU
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread