> 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
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
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
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
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
> 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
In trying to track down a bug related to hwclock hanging my x86_64
machine, I found myself reading include/asm-generic/rtc.h carefully with
a chipset spec for several RTC chips (in particular, the granddaddy, the
MC146818A) in my hand.
I found that the code in get_rtc_time() is very, very
In trying to track down a bug related to hwclock hanging my x86_64
machine, I found myself reading include/asm-generic/rtc.h carefully with
a chipset spec for several RTC chips (in particular, the granddaddy, the
MC146818A) in my hand.
I found that the code in get_rtc_time() is very, very
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 more
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
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
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
12 matches
Mail list logo
