On 12/04/2017 17:51, guangrong.x...@gmail.com wrote: > The root cause is that the clock will be lost if the periodic period is > changed as currently code counts the next periodic time like this: > next_irq_clock = (cur_clock & ~(period - 1)) + period; > > consider the case if cur_clock = 0x11FF and period = 0x100, then the > next_irq_clock is 0x1200, however, there is only 1 clock left to trigger > the next irq. Unfortunately, Windows guests (at least Windows7) change > the period very frequently if it runs the attached code, so that the > lost clock is accumulated, the wall-time become faster and faster
Very interesting. However, I think that the above should be exactly how the RTC should work. The original RTC circuit had 22 divider stages (see page 13 of the datasheet[1], at the bottom right), and the periodic interrupt taps the rising edge of one of the dividers (page 16, second paragraph). The datasheet also never mentions a comparator being used to trigger the periodic interrupts. Have you checked that this Windows bug doesn't happen on real hardware too? Or is the combination of driftfix=slew and changing periods that is a problem? The series also does more than this fix (or workaround), so I will review it anyway. [1] http://www.nxp.com/assets/documents/data/en/data-sheets/MC146818.pdf Thanks, Paolo
