> I understand that SMM/SMI servicing can take a long time, but SMM/SMI
> shouldn't happen while interrupts are masked using local_irq_disable()
Don't bet on it.
> [included in spin_lock_irq()], at least on x86-architectures. If
> SMM/SMI can happen even then, the NMI fix below could be gen
On 08/16/2007 02:26 AM, David P. Reed wrote:
My mention of NMI (which by definition can't be masked) is because NMI
Well, not by the CPU it can't, but on a PC, masking NMIs is a simple matter
of setting bit 7 of I/O port 0x70 to 1 (it seems the kernel does not provide
an interface for it tho
Alan:
Thanks for the comment. I will code a patch, and include a sanity check
as you suggested, and send it for review. Just to clarify one concern
your note raised:
I understand that SMM/SMI servicing can take a long time, but SMM/SMI
shouldn't happen while interrupts are masked using loca
David P. Reed wrote:
>
> The idea in the comment at the top seems to suggest that the author
> thought that the UIP flag indicates an update is in progress at that
> very instant, so one needs to synchronize with the "falling edge" of
> that flag to ensure that one can read the RTC state without i
> So the proper way to read the RTC contents is to read the UIP flag, and
> if zero, read all the RTC registers with interrupts masked completely,
> so all reads happen in the 224 usec window. (NMI can still be a
> problem, but you can have NMI's set a flag that forces a retry).
SMM/SMI is mor
5 matches
Mail list logo
