On 8 Feb 01 at 6:04, Mikael Pettersson wrote:
> ordering and offsets in processor.h and head.S. The resulting
> kernel works ok on my UP P6.
> (Petr: can you check that it still works on your K7?)
I'll try.
I have another question for UP APIC NMI: As I reported some time ago,
if performance counters overflow when LVTPC has 'disabled' bit set,
NMI is lost forever. This causes problems with VMware - it has to
disable NMI deliveries during CR3 (memory mapping) switching, and if
performance counter overflows at that time, you'll not receive another
NMI for couple of days on K7 (4.1 * 65536 seconds on fully loaded 1GHz
Athlon. And 410 * 65536 seconds on idle Athlon)...
So it came to my mind - why (on K7 we easy can, as counter has 48 bits)
we do not reload NMI watchdog in each timer interrupt with 5sec timeout,
and if we receive even one NMI, we are locked up? It should increase
performance, as we'll do same number of MSR writes anyway (100/s), but
we will not receive any NMI during normal operation, so we save time
spent in processing this. Or do I miss something?
It may be problem on P6, as it has only 32bit perfctrs, so we are limited
to 4.1s watchdog timeout on 1GHz PIII :-(
Thanks,
Petr Vandrovec
[email protected]
On Thu, 8 Feb 2001, Petr Vandrovec wrote:
> So it came to my mind - why (on K7 we easy can, as counter has 48 bits)
> we do not reload NMI watchdog in each timer interrupt with 5sec timeout,
> and if we receive even one NMI, we are locked up? It should increase
> performance, as we'll do same number of MSR writes anyway (100/s), but
> we will not receive any NMI during normal operation, so we save time
> spent in processing this. Or do I miss something?
I guess it's the external watchdog heritage. The code is common for both
kinds of the watchdog at the moment. It might get separated, I suppose.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: [email protected], PGP key available +