Re: [patch] enabling APIC and NMI watchdog on UP systems
Philip J. Mucci wrote: > Basically, reading the counters is a 2 step process: read the mmapped > virtual counters and add that to the contents of rdpmc(). This means > that (at least for the x86 series) the kernel interface only needs to > 'guard' access to the MSR to make sure the user doesn't set up anything > pathological. This same kind of interface is also possible for the > UltraSparc. For other systems where a lower IPL is required, the > interface needs to be a fast-path syscall interface. That sounds similar to the vsyscall interface Ingo's been working on. Why not use the read-only kernel page used for fast gettimeofday() calibration with MSR offsets? It's slightly more overhead than inlining the code, but it is still only a small overhead (no kernel entry, just a function call to code in a user-readable page). People doing advanced dynamic compilation techniques can always trace the vsyscall code and inline equivalent code directly into their hot paths ;-) -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
Hi David, Ingo, Keith, Kier and all, As the developer of PAPI, I can only reiterate what Ingo and David have suggested. The user base of people wanting access to performance counters has greatly expanded. PAPI has now been out for over a year and a half and we get pings from developers across the globe working with the performance counters on everything from performance tool development, to database tuning, to feedback directed compilation. For the Linux port, we originally (in 2.0 and 2.2) used David's patch with some minor modifications that I made for inheritance of the MSR when an option is set. For 2.4 we have migrated to Mikael Petterson's excellent perfctr patch which provides us with extrememly low latency access to the counters via a memory mapped interface. The only outstanding issue with that patch as far as PAPI goes is how MSR/counter inheritance is handled by threads and making the virtualized TSC run freely from 'attach' time. As far as a kernel interface goes, we need to remember that most architectures allow the counters to be read in user mode, which lends itself very nicely to the kind of implementation that Mikael has done. Basically, reading the counters is a 2 step process: read the mmapped virtual counters and add that to the contents of rdpmc(). This means that (at least for the x86 series) the kernel interface only needs to 'guard' access to the MSR to make sure the user doesn't set up anything pathological. This same kind of interface is also possible for the UltraSparc. For other systems where a lower IPL is required, the interface needs to be a fast-path syscall interface. I would like to point out that this is not just something that us hackers need, but now that multi-million dollar superclusters are being sold by the dozen, hardware based performance analysis and tuning is a real necessity. I know the TurboLinux folks are playing here, but no one has come out an championed a kernel interface. In fact, there is at least one commercial product (DEEP/MPI from PSRV) I know of that uses the hardware counters (and PAPI for that matter) that is dependent upon us academics to make sure we keep the kernel patch up to date. Now, back to the subject at hand, if the NMI mechanism is coded properly, we can also use it to generate statistical profiles instead of emulating them in user land. Well, that's all for now. If anyone is motivated to spearhead a formal interface to the PMC's, please let us know. Thanks for reading this novel, -Philip Mucci IBM Research UTK Innovative Computing Lab. David Mentré wrote: > > Ingo Molnar <[EMAIL PROTECTED]> writes: > > > that having all said, i'm not against a generic, nonpriviledged (kernel > > based) performance counter API within the kernel (if there is demand), and > > such an API should of course have close control over the contents of the > > performance counter registers, and in this case the NMI oopser has to > > cooperate. Something like doing per-process performance monitoring and > > potentially switching the MSRs on task-switch. > > regarding perf. counters, there is also the PAPI initiative, standard > *user level* API : > > Performance Data Standard and API >http://icl.cs.utk.edu/projects/papi/ > > Linux 2.2 and 2.4 (CVS) are actively supported with a patch. Probably > PAPI developers would also be glad to have a standard linux kernel API. > > d. > -- > [EMAIL PROTECTED] -- http://www.irisa.fr/prive/dmentre/ > Linux SMP HOWTO: http://www.irisa.fr/prive/dmentre/smp-howto/ > Opinions expressed here are only mine. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Sun, 1 Oct 2000 23:30:14 +0200 (MET DST), Mikael Pettersson <[EMAIL PROTECTED]> wrote: >The upapic-2.4.0-test9-C3 patch has another problem. > >On Fri, 29 Sep 2000, Udo A. Steinberg wrote: > >>I've been giving the patch a try, however it hangs my machine during boot. >>Here's the important bits from console: >> >>Local APIC disabled by BIOS -- reenabling >>found and enabled local APIC! >> >>It then locks up in Calibrating delay loop... > >My own patch for enabling the local APIC on UP enables it from >arch/i386/kernel/setup.c, immediately after init_apic_mappings(). Ingo and I have some minor disagreements about how the NMI on UP patch should be done. My current version is in ftp://ftp.ocs.com.au/pub/upapic-2.4.0-test9-C3-K3.gz. It is Ingo's patch plus my reinstatement of bits that he removed but that I believe are required, especially for SMP boxes. Moving clear_local_APIC() from setup_local_APIC() back to connect_bsp_APIC() fixes the lock up in Calibrating delay loop, this is included in my patch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Sat, 30 Sep 2000, Ingo Molnar wrote:
>
> On Sat, 30 Sep 2000, Keith Owens wrote:
>
> > via /dev/msr. On SMP you end up with two sources of NMI, local APIC
> > on every cpu plus IO-APIC. The code in linux/arch/i386/kernel/traps.c
> > resets PERFCTR1 on every NMI, [...]
>
> yep, thanks, thats a bug, i'll fix it.
>
> Ingo
The upapic-2.4.0-test9-C3 patch has another problem.
On Fri, 29 Sep 2000, Udo A. Steinberg wrote:
>I've been giving the patch a try, however it hangs my machine during boot.
>Here's the important bits from console:
>
>Local APIC disabled by BIOS -- reenabling
>found and enabled local APIC!
>
>It then locks up in Calibrating delay loop...
What's happening is that on boot, the APIC is disabled (so the
external interrupt pins bypass it) and its contents is in a "masked"
state. After toggling the enable flags in MSR 0x1B and APIC SPIV,
interrupts are routed via the APIC; however, the LVT entries are
still masked which prevents any interrupts from being delivered.
The symptom is a hang in calibrate_delay(). (Unless your UP BIOS
initialises the APIC to through-local mode, which is unlikely.)
Intialising the local APIC in the start_kernel() -> smp_init() ->
IO_APIC_init_uniprocessor() path is too late. The kernel needs
interrupts long before that.
My own patch for enabling the local APIC on UP enables it from
arch/i386/kernel/setup.c, immediately after init_apic_mappings().
I've attached a version of this patch which has been retrofitted
to work on top of Ingo's upapic-2.4.0-test9-C3 patch. With this,
my kernels boot and work ok (well, apart from not having perfctrs
any more 8-< ).
BTW, does anyone have any docs on the AMD K7's local APIC? The
K7 BIOS manual is supposed to document the local APIC, but it
doesn't appear to be available at their web site...
/Mikael
--- linux-2.4.0-test9-pre7-upapic/arch/i386/kernel/apic.c.~1~ Fri Sep 29 14:58:40
2000
+++ linux-2.4.0-test9-pre7-upapic/arch/i386/kernel/apic.c Sun Oct 1 21:53:46
+2000
@@ -198,10 +198,16 @@
* Original code written by Keir Fraser
*/
-int detect_init_APIC (void)
+static int __init detect_init_APIC (void)
{
u32 h, l, dummy, features;
+ if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL) {
+ /* Does anyone outside AMD have docs for the K7 local APIC? */
+ printk("Cannot enable local APIC on non-Intel processors\n");
+ return -1;
+ }
+
if (boot_cpu_data.x86 < 5) {
printk("No local APIC on pre-Pentium Intel processors\n");
return -1;
@@ -242,11 +248,82 @@
}
/*
+ * Initialize a P6's local APIC for UP operation (through-local).
+ * Assumes that init_apic_mappings() has mapped the local APIC.
+ * TODO: check how to do this for K7 and P4.
+ * Original code written by Mikael Pettersson.
+ */
+void __init init_local_APIC(void)
+{
+ unsigned int msr_orig_low, msr_orig_high;
+ unsigned int spiv_orig;
+ unsigned int lvr;
+ int init_done;
+ unsigned int value;
+
+ if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+ return;
+ if (boot_cpu_data.x86 != 6)
+ return;
+ init_done = 0;
+ rdmsr(0x1B, msr_orig_low, msr_orig_high);
+ if (!(msr_orig_low & (1<<11))) {
+ wrmsr(0x1B, msr_orig_low|(1<<11), msr_orig_high);
+ printk(__FUNCTION__ ": enabled local APIC msr\n");
+ init_done = 1;
+ }
+ spiv_orig = apic_read(APIC_SPIV);
+ if (!(spiv_orig & (1<<8))) {
+ value = spiv_orig;
+ value &= ~APIC_VECTOR_MASK;
+ value |= (1<<8)|SPURIOUS_APIC_VECTOR;
+ apic_write(APIC_SPIV, value);
+ printk(__FUNCTION__ ": enabled local APIC SPIV\n");
+ init_done = 1;
+ }
+ /*
+* Make sure the page map points to the real thing.
+*/
+ lvr = apic_read(APIC_LVR);
+ if (!APIC_INTEGRATED(lvr))
+ goto out_init;
+ if (GET_APIC_MAXLVT(lvr) != 4)
+ goto out_init;
+ /*
+* Careful! Writing a zero vector to LVTT or LVTPC causes a
+* 0x40 APIC error (Received Illegal Vector) even if the entry
+* is masked. We therefore supply non-zero vectors below.
+*/
+ if (init_done) {/* on UP, we're the first to init it */
+ apic_write(APIC_LVT0, APIC_DM_EXTINT|APIC_LVT_LEVEL_TRIGGER);
+ apic_write(APIC_LVT1, APIC_DM_NMI);
+ apic_write(APIC_ESR, 0);
+ apic_read(APIC_ESR);
+ apic_read(APIC_LVTERR);
+ apic_write(APIC_LVTERR, ERROR_APIC_VECTOR);
+ apic_write(APIC_ESR, 0);
+ apic_read(APIC_ESR);
+ apic_write(APIC_LVTT, APIC_LVT_MASKED|LOCAL_TIMER_VECTOR);
+ }
+ apic_write(APIC_LVTPC, APIC_LVT_MASKED|ERROR_APIC_VECTOR);
+ boot_cpu_data.x86_capability |= X86_FEATURE_AP
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Sat, 30 Sep 2000, Keith Owens wrote: > via /dev/msr. On SMP you end up with two sources of NMI, local APIC > on every cpu plus IO-APIC. The code in linux/arch/i386/kernel/traps.c > resets PERFCTR1 on every NMI, [...] yep, thanks, thats a bug, i'll fix it. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000 10:00:37 +0200 (CEST), Ingo Molnar <[EMAIL PROTECTED]> wrote: >On Fri, 29 Sep 2000, Keith Owens wrote: > >> arch/i386/kernel/msr.c has been there since at least 2.4.0-test1. A > >there is nothing performance-counter specific about /dev/msr. There is no >highlevel performance-counter logic in the kernel. So if the kernel >decides to use one of them, that should not be more of a problem than some >other user already using the performance counter. /dev/msr exposes all msrs to user space, including performance counters. There is code out there that uses /dev/msr to get performance data. My worry was not about the kernel using performance counters, because there is no such use. I worry about userspace code that is already using performance counters. >You can simply turn performance counters off via /dev/msr, just like you would clear them prior use anyway. Sorry, no. As your patch stands, on UP you can turn off PERFCTR1 NMI via /dev/msr. On SMP you end up with two sources of NMI, local APIC on every cpu plus IO-APIC. The code in linux/arch/i386/kernel/traps.c resets PERFCTR1 on every NMI, whether PERFCTR1 was the NMI source or not, this makes PERFCTR1 permanently unavailable on SMP boxes. Even if the user changes EVNTSEL1 via /dev/msr, traps.c on SMP will still overwrite the PERFCTR1 value on every NMI. Not only that but the NMI oopser now kicks in twice as fast on SMP. Problem 1: We need a field nmi_watchdog_source, I put that code in there for a good reason. Problem 2: Booting multiple cpu machines when NMI is generated via local APIC causes problems. Each cpu spins in start_secondary() until all cpus are active. The local APIC NMI oopser is active at this point and after about the fifth cpu it kicks in. This problem exists in my kdb patch as well. The easiest solution is to add field nmi_watchdog_source and set that to 2 (SMP mode) at the start of do_boot_cpu(). Problem 3: You replaced my use of wrmsr_eio with a test on the return code with wrmsr and no return code test. wrmsr_eio returns -EIO for an invalid msr, wrmsr will oops. I was allowing for hardware that has a local APIC but does not support performance counters, does AMD fall into this category? wrmsr_eio is much safer at almost zero extra execution cost. I can live without a config or /proc option for adjusting NMI oopser. Field nmi_watchdog_source is required, wrmsr_eio is recommended. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
Ingo Molnar <[EMAIL PROTECTED]> writes: > that having all said, i'm not against a generic, nonpriviledged (kernel > based) performance counter API within the kernel (if there is demand), and > such an API should of course have close control over the contents of the > performance counter registers, and in this case the NMI oopser has to > cooperate. Something like doing per-process performance monitoring and > potentially switching the MSRs on task-switch. regarding perf. counters, there is also the PAPI initiative, standard *user level* API : Performance Data Standard and API http://icl.cs.utk.edu/projects/papi/ Linux 2.2 and 2.4 (CVS) are actively supported with a patch. Probably PAPI developers would also be glad to have a standard linux kernel API. d. -- [EMAIL PROTECTED] -- http://www.irisa.fr/prive/dmentre/ Linux SMP HOWTO: http://www.irisa.fr/prive/dmentre/smp-howto/ Opinions expressed here are only mine. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Ingo Molnar wrote: > yep, this was my point. Eg. i dont think we cleared the performance > counters on AP APICs before, so in theory, if some other OS sets them up > and Linux is soft-booted (or loadlin-ed), then there might be boot > problems. Hmm, on a second thought, I recalled local APIC registers get cleared on a receipt of an INIT IPI. So this should really not matter (unless there are errata in certain hardware), apart from the BSP APIC in the PIC mode, which we don't send an INIT IPI. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, John Levon wrote: > prumpf has been talking about using some counter information for > scheduling/VM purposes as well ... yep, i planned something like this about 2 years ago - in fact the current->avg_slice scheduler feature some time ago (which used the cycle counter to measure timeslices) was one variant of this. Unfortunately it didnt work out so we removed it. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Ingo Molnar wrote: > that having all said, i'm not against a generic, nonpriviledged (kernel > based) performance counter API within the kernel (if there is demand), and > such an API should of course have close control over the contents of the > performance counter registers, and in this case the NMI oopser has to > cooperate. Something like doing per-process performance monitoring and > potentially switching the MSRs on task-switch. But as far as i've seen, > most people who want to have that kind of finegrained information about > their system have no problem doing these things as root, and this is a > much simpler implementation. > > Ingo Of course Mikael Petersson's perfctr patch has been providing such for a while now, and many people use it. My forthcoming profiler makes use the counters in a different way, but as long as such an API is clean enough to allow the various different uses w/o hacky patches I think this would be a great idea. prumpf has been talking about using some counter information for scheduling/VM purposes as well ... thanks john -- "The words CON and NUL Are reserved by the system. Don't ask; they just are." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Ingo Molnar wrote: > i'm wondering wether this missing clear_APIC() could explain some of the > more mysterious boot problems we had? I don't think so. Unless we have an i82489DX APIC in th PIC mode, the BSP APIC must be set up into the Virtual Wire mode or DOS, etc. won't work. AP APICs might be setup randomly, though. Clearing of APICs should not hurt but we have to take care not to lose any interrupt, as this may lead to a lockup (especially in the "noapic" mode). In case of mysterios problems, I would study the setup code paths thoroughly, though. APICs tend to lose interrupts when the respective entries are disabled and the source might not be willing to reassert the IRQ (see the problem with the 8259A glue logic with certain EISA boards, for example). Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Maciej W. Rozycki wrote: > [...] AP APICs might be setup randomly, though. [...] yep, this was my point. Eg. i dont think we cleared the performance counters on AP APICs before, so in theory, if some other OS sets them up and Linux is soft-booted (or loadlin-ed), then there might be boot problems. > Clearing of APICs should not hurt but we have to take care not to lose > any interrupt, as this may lead to a lockup (especially in the > "noapic" mode). yep. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Keir Fraser wrote: > Thanks for the info: I'd entirely forgotten about the inter-APIC comms > bus. That given, I have no problem with clearing the perfctr before > use. The NMI oopser has saved my bacon on more than one occasion :) i'm glad to hear that :-) If you have an SMP system then i agree we should not touch the performance counter at all - i only did it my patch to give it some testing. that having all said, i'm not against a generic, nonpriviledged (kernel based) performance counter API within the kernel (if there is demand), and such an API should of course have close control over the contents of the performance counter registers, and in this case the NMI oopser has to cooperate. Something like doing per-process performance monitoring and potentially switching the MSRs on task-switch. But as far as i've seen, most people who want to have that kind of finegrained information about their system have no problem doing these things as root, and this is a much simpler implementation. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
> what is wrong with clearing the first performance counter before using it? > The NMI oopser is completely nonintrusive. > > so on UP systems you'll have to choose between the NMI oopser and other > uses of the first counter. You can save/restore the contents of the first > counter if you want to reactivate the NMI oopser. This is all user-space > policy, the kernel doesnt mind. Thanks for the info: I'd entirely forgotten about the inter-APIC comms bus. That given, I have no problem with clearing the perfctr before use. The NMI oopser has saved my bacon on more than one occasion :) -- Keir - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Keir Fraser wrote: > Another question relating to the setup of local APICs on current > -testX kernels: how are external interrupts routed through to the > processor? I thought that setup_local_APIC() used LVT0 to pick up > external interrupts, but setup_nmi_watchdog() reconfigures LVT0 into > NMI mode! I/O APIC interrupts get delivered to local APICs through the inter-APIC serial bus. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Keir Fraser wrote: > > Is it really necessary to use one of the event counters ? this means > > those of us using event counters from modules can't use this oopser at > > the same time, which is a pity. > Indeed. What was wrong with the existing method, where you route an > external timer in AEOI mode through LVT0? Is it inefficient, or known > to fail on some boards, or something like that? it needs an existing IOAPIC chip, which is not present in the majority of single-processor systems. what is wrong with clearing the first performance counter before using it? The NMI oopser is completely nonintrusive. so on UP systems you'll have to choose between the NMI oopser and other uses of the first counter. You can save/restore the contents of the first counter if you want to reactivate the NMI oopser. This is all user-space policy, the kernel doesnt mind. > Another question relating to the setup of local APICs on current > -testX kernels: how are external interrupts routed through to the > processor? [...] they are delivered by the IOAPIC, to one (or more) of the local APICs via the APIC bus, the local APIC then (after IRQ arbitration) interrupts the CPU core. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Maciej W. Rozycki wrote: > > i've left the i82489DX path unchanged - except for the (generic) fix to > > consistencly clear the local APIC in on all CPUs, not just the BSP. I > > cannot see how this can impact the i82489DX path. > > I've missed that bit, sorry. I'll look at the patch more deeply over > the weekend. i'm wondering wether this missing clear_APIC() could explain some of the more mysterious boot problems we had? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Ingo Molnar wrote: > i've left the i82489DX path unchanged - except for the (generic) fix to > consistencly clear the local APIC in on all CPUs, not just the BSP. I > cannot see how this can impact the i82489DX path. I've missed that bit, sorry. I'll look at the patch more deeply over the weekend. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
> > ... and adds the enabling code of Keith Owens which
> > programs P6 performance counter 0 as an NMI. (i simplified the code alot -
> > there is no problem at all with getting NMIs from two sources, and it's
> > not necessary to make it configurable.)
>
> Is it really necessary to use one of the event counters ? this means those
> of us using event counters from modules can't use this oopser at
> the same time, which is a pity.
Indeed. What was wrong with the existing method, where you route an
external timer in AEOI mode through LVT0? Is it inefficient, or known
to fail on some boards, or something like that?
Another question relating to the setup of local APICs on current
-testX kernels: how are external interrupts routed through to the
processor? I thought that setup_local_APIC() used LVT0 to pick up
external interrupts, but setup_nmi_watchdog() reconfigures LVT0 into
NMI mode!
On my SMP box, running test6, the following line:
printk("CPU#%d: %08x/%08x\n", smp_processor_id(),
apic_read(APIC_LVT0), apic_read(APIC_LVT1));
yields the result:
CPU#0: 0400/0400
CPU#1: 0400/00010400
That is, all the LINT[0:1] pins on all processors are configured into
NMI mode. That given, I don't see how external interrupts work
(although obviously they must do :-)
I'm really curious as to how this magic works...
-- Keir Fraser
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, John Levon wrote: > Is it really necessary to use one of the event counters ? this means > those of us using event counters from modules can't use this oopser at > the same time, which is a pity. well, you can still use the other event counter. And you can clear the first counter as well. The Intel performance monitoring utility (perfmon?) has been using this NMI technique for years, so it's probably the only way to get periodic NMIs on UP systems, without any extra hardware. > Can you not set up the actual APIC timer on a local APIC to deliver > NMIs ? (Sorry, been a while since I read the intel docs) unfortunately not. It ignores this setting. I tried it years ago :-) > On the other hand it's good to see that us module event counter users > don't have to do that ugly fixmap thing to get back real access to the > local APIC, now that the zero-page thing is gone :) the zero-page is added if there is no APIC detected, so it's intended behavior - if there is an APIC in a CPU then we definitely want to enable it during bootup! Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, John Levon wrote: > Is it really necessary to use one of the event counters ? this means those > of us using event counters from modules can't use this oopser at > the same time, which is a pity. > > > Can you not set up the actual APIC timer on a local APIC to deliver NMIs > ? (Sorry, been a while since I read the intel docs) > Ugh, after checking, it seems delivery mode is not settable for the APIC timer. Sorry for the confusion. Why did Intel make it like this :/ I suppose nmi_watchdog=0 is the only option ... thanks john -- "The words CON and NUL Are reserved by the system. Don't ask; they just are." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Thu, 28 Sep 2000, Ingo Molnar wrote: > > the attached patch (against test9-pre7) is a cleaned up version Keir > Fraser's APIC-on-UP patch, and adds the enabling code of Keith Owens which > programs P6 performance counter 0 as an NMI. (i simplified the code alot - > there is no problem at all with getting NMIs from two sources, and it's > not necessary to make it configurable.) > > i'd like to hear about how this patch works for people - it works here on > SMP systems and on P6 systems. The watchdog is enabled unconditionally - > this should significantly help debugging lockups on UP systems as well! > (thanks Keir and Keith!) > > Ingo > I can't test it right now, but I had a question or two ... Is it really necessary to use one of the event counters ? this means those of us using event counters from modules can't use this oopser at the same time, which is a pity. Can you not set up the actual APIC timer on a local APIC to deliver NMIs ? (Sorry, been a while since I read the intel docs) Vincent Oberle has an apic timer module which uses these (link from kernelnewbies.org for anyone interested). On the other hand it's good to see that us module event counter users don't have to do that ugly fixmap thing to get back real access to the local APIC, now that the zero-page thing is gone :) thanks john -- "The words CON and NUL Are reserved by the system. Don't ask; they just are." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Maciej W. Rozycki wrote: > which your patch addresses. Please leave the i82489DX path unchanged > -- it's too fragile. i've left the i82489DX path unchanged - except for the (generic) fix to consistencly clear the local APIC in on all CPUs, not just the BSP. I cannot see how this can impact the i82489DX path. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Thu, 28 Sep 2000, Ingo Molnar wrote: > the attached patch (against test9-pre7) is a cleaned up version Keir > Fraser's APIC-on-UP patch, and adds the enabling code of Keith Owens which > programs P6 performance counter 0 as an NMI. (i simplified the code alot - > there is no problem at all with getting NMIs from two sources, and it's > not necessary to make it configurable.) I don't like your changes to connect_bsp_APIC() and the semantics of pic_mode. As the PIC mode is only meaningful for i82489DX configurations, it is irrelevant to integrated APIC implementations which your patch addresses. Please leave the i82489DX path unchanged -- it's too fragile. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--+ +e-mail: [EMAIL PROTECTED], PGP key available+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Keith Owens wrote: > arch/i386/kernel/msr.c has been there since at least 2.4.0-test1. A there is nothing performance-counter specific about /dev/msr. There is no highlevel performance-counter logic in the kernel. So if the kernel decides to use one of them, that should not be more of a problem than some other user already using the performance counter. You can simply turn performance counters off via /dev/msr, just like you would clear them prior use anyway. If there was some existing kernel-based API to give unpriviledged access to performance counters then i would agree - but right now it takes extra action by a knowledgable root to use /dev/msr. > I originally did that but it users have to tweak their boot files > whenever they install a new kernel. Making it a config option > propagates the user's requirements from one kernel build to another. making an extra config option unnecessery litters the kernel with #ifdefs. Why should it be a config option beyond CONFIG_X86_APIC if our goal is to run it on as many boxes as possible? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000 03:03:30 +0200 (CEST), Ingo Molnar <[EMAIL PROTECTED]> wrote: > >On Fri, 29 Sep 2000, Keith Owens wrote: > >> [...] You prefer to make NMI for UP mandatory, change the existing >> behaviour and force people who use performance counters to turn off >> EVNTSEL1 themselves. [...] > >no, AFAIK there is no performance counter support in the vanilla kernel, >but there is an NMI oopser. arch/i386/kernel/msr.c has been there since at least 2.4.0-test1. A web search reveals a lot of other patches for performance counter libraries on Linux. http://www.scl.ameslab.gov/Projects/Rabbit/ is a good start, it indicates that people are already using the counters. >And even if there was performance counter >support, having a default NMI oopser on UP *is* a much higher priority. Agreed, having the support is a high priority. Changing the default behaviour of the performance counters is where we differ. >and there is no forcing here. nmi_watchdog=0 on bootup and the NMI >watchdog is disabled. (right now this is not enforced for the APIC-NMI, >but thats a detail.) I originally did that but it users have to tweak their boot files whenever they install a new kernel. Making it a config option propagates the user's requirements from one kernel build to another. Let's just agree to disagree and put your patch in the mainline kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Keith Owens wrote: > [...] You prefer to make NMI for UP mandatory, change the existing > behaviour and force people who use performance counters to turn off > EVNTSEL1 themselves. [...] no, AFAIK there is no performance counter support in the vanilla kernel, but there is an NMI oopser. And even if there was performance counter support, having a default NMI oopser on UP *is* a much higher priority. and there is no forcing here. nmi_watchdog=0 on bootup and the NMI watchdog is disabled. (right now this is not enforced for the APIC-NMI, but thats a detail.) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000 01:13:06 +0200 (CEST), Ingo Molnar <[EMAIL PROTECTED]> wrote: >On Fri, 29 Sep 2000, Keith Owens wrote: >> Using performance counter 1 for NMI conflicts with using the >> performance counters for tuning. IMHO it is better to default to NMI >> off for UP so we do not disturb people who are doing performance >> monitoring. [...] > >the number of people experiencing hard lockups, and the importance of >debugging these (annoying) lockups IMO far outweighs the potential >inconvenience caused by having to disable the NMI oopser for performance >tuning. I did not want to disturb anybody who was already using the performance counters for tuning so I made NMI for UP optional. You prefer to make NMI for UP mandatory, change the existing behaviour and force people who use performance counters to turn off EVNTSEL1 themselves. And they must remember to reprogram EVNTSEL1 to reactivate NMI after they have finished tuning. This is a philosophical difference, not a technical one, we will just have to agree to disagree. Either way it will be nice to get NMI for UP into the standard kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Keith Owens wrote:
> Using performance counter 1 for NMI conflicts with using the
> performance counters for tuning. IMHO it is better to default to NMI
> off for UP so we do not disturb people who are doing performance
> monitoring. [...]
the number of people experiencing hard lockups, and the importance of
debugging these (annoying) lockups IMO far outweighs the potential
inconvenience caused by having to disable the NMI oopser for performance
tuning.
> That then requires a mechanism for configuring the UP NMI and
> activating it on the fly, which complicates the code.
no.
> set_nmi_counter_local() has to be called after every NMI to reset the
oops - i *am* reprogramming the counter (i obviously tested wether the NMI
oopser works on a non-SMP P6 system, and checked the NMI counter in
/proc/interrupts), but it was left out of the patch by accident [forgot to
create a .orig file]. I've attached the -C3 patch.
Ingo
--- linux/include/asm-i386/apic.h.orig Thu Sep 28 05:18:49 2000
+++ linux/include/asm-i386/apic.h Thu Sep 28 05:29:14 2000
@@ -71,6 +71,7 @@
extern int verify_local_APIC (void);
extern void cache_APIC_registers (void);
extern void sync_Arb_IDs(void);
+extern int detect_init_APIC (void);
extern void setup_local_APIC (void);
extern void init_apic_mappings(void);
extern void smp_local_timer_interrupt(struct pt_regs * regs);
--- linux/include/asm-i386/msr.h.orig Thu Oct 7 10:17:09 1999
+++ linux/include/asm-i386/msr.hThu Sep 28 05:33:02 2000
@@ -30,3 +30,21 @@
: "=a" (low), "=d" (high) \
: "c" (counter))
+#define MCG_STATUS_MSR 0x17a
+#define MCG_CAP0x179
+#define MCG_CTL0x17b
+#define MC0_BASE 0x400
+#define MC0_CTL_OFFSET0x0
+#define MC0_STATUS_OFFSET 0x1
+#define MC0_ADDR_OFFSET 0x2
+#define MC0_MISC_OFFSET 0x3
+#define MC0_BANK_COUNT0x4
+#define DEBUGCTLMSR0x1d9
+#define LASTBRANCHFROMIP 0x1db
+#define LASTBRANCHTOIP 0x1dc
+#define LASTINTFROMIP 0x1dd
+#define LASTINTTOIP 0x1de
+#define PERFCTR00xc1
+#define PERFCTR10xc2
+#define EVNTSEL00x186
+#define EVNTSEL10x187
--- linux/include/asm-i386/processor.h.orig Thu Sep 28 06:39:06 2000
+++ linux/include/asm-i386/processor.h Thu Sep 28 06:39:27 2000
@@ -127,6 +127,8 @@
(boot_cpu_data.x86_capability & X86_FEATURE_FXSR)
#define cpu_has_xmm \
(boot_cpu_data.x86_capability & X86_FEATURE_XMM)
+#define cpu_has_apic \
+ (boot_cpu_data.x86_capability & X86_FEATURE_APIC)
extern char ignore_irq13;
--- linux/include/asm-i386/timex.h.orig Thu Sep 28 06:47:10 2000
+++ linux/include/asm-i386/timex.h Thu Sep 28 06:47:15 2000
@@ -45,4 +45,6 @@
#endif
}
+extern unsigned long cpu_khz;
+
#endif
--- linux/arch/i386/kernel/apic.c.orig Thu Sep 28 05:07:18 2000
+++ linux/arch/i386/kernel/apic.c Thu Sep 28 07:06:44 2000
@@ -84,15 +84,7 @@
void __init connect_bsp_APIC(void)
{
if (pic_mode) {
- /*
-* Do not trust the local APIC being empty at bootup.
-*/
- clear_local_APIC();
- /*
-* PIC mode, enable symmetric IO mode in the IMCR,
-* i.e. connect BSP's local APIC to INT and NMI lines.
-*/
- printk("leaving PIC mode, enabling symmetric IO mode.\n");
+ printk("leaving PIC mode, enabling APIC mode.\n");
outb(0x70, 0x22);
outb(0x01, 0x23);
}
@@ -107,7 +99,7 @@
* interrupts, including IPIs, won't work beyond
* this point! The only exception are INIT IPIs.
*/
- printk("disabling symmetric IO mode, entering PIC mode.\n");
+ printk("disabling APIC mode, entering PIC mode.\n");
outb(0x70, 0x22);
outb(0x00, 0x23);
}
@@ -201,12 +193,98 @@
| APIC_DM_INIT);
}
+/*
+ * Detect and enable local APICs on non-SMP boards.
+ * Original code written by Keir Fraser
+ */
+
+int detect_init_APIC (void)
+{
+ u32 h, l, dummy, features;
+
+ if (boot_cpu_data.x86 < 5) {
+ printk("No local APIC on pre-Pentium Intel processors\n");
+ return -1;
+ }
+
+ if (boot_cpu_data.x86 == 6) {
+ /*
+* Some BIOSes disable the local APIC in the APIC_BASE MSR.
+* This can only be done in software for PPro and above.
+*/
+ rdmsr(0x1b, l, h);
+ if (!(l & 0x800)) {
+ printk("Local APIC disabled by BIOS -- reenabling.\n");
+ l |= 0x800;
+ wrmsr(0x1b, l, h);
+
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Thu, 28 Sep 2000 21:19:29 +0200 (CEST),
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>the attached patch (against test9-pre7) is a cleaned up version Keir
>Fraser's APIC-on-UP patch, and adds the enabling code of Keith Owens which
>programs P6 performance counter 0 as an NMI. (i simplified the code alot -
>there is no problem at all with getting NMIs from two sources, and it's
>not necessary to make it configurable.)
Using performance counter 1 for NMI conflicts with using the
performance counters for tuning. IMHO it is better to default to NMI
off for UP so we do not disturb people who are doing performance
monitoring. That then requires a mechanism for configuring the UP NMI
and activating it on the fly, which complicates the code.
AFAICT your patch will not generate local APIC NMIs fast enough. From
kdb v1.5-beta2.
int set_nmi_counter_local(void)
{
extern unsigned long cpu_khz;
if (!(boot_cpu_data.x86_capability & X86_FEATURE_APIC))
return(-EIO);
if (nmi_watchdog_source && nmi_watchdog_source != 1)
return(0); /* Not using local APIC */
return wrmsr_eio(PERFCTR1, -(cpu_khz/HZ*1000), 0);
}
set_nmi_counter_local() has to be called after every NMI to reset the
counter. Otherwise the counter is zero (it just overflowed) and will
not generate another NMI until it loops all the way round to 2**40
again. If you are going to reprogram PERFCTR1 for every NMI then you
do not want to do that unless PERFCTR1 really is the NMI source, again
it will conflict with real use of the performance counters so we need
to track the source and make it configurable.
I am basing this on Intel ia32 arch vol3, 24319202.pdf
15.6.2. Monitoring Counter Overflow
...
When interrupted by a counter overflow, the interrupt handler needs to
perform the following actions:
* Save the instruction pointer (EIP register), code-segment selector,
TSS segment selector, counter values and other relevant information
at the time of the interrupt.
* Reset the counter to its initial setting and return from the
interrupt.
If you tested a UP compile on an SMP box, you probably got NMI via the
IO-APIC which hides the lack of counter reset. I had to hack
smp_scan_config() to immediately return(0) so it would not pick up the
SMP config and not use the IO-APIC for NMI.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Udo A. Steinberg wrote: > Machine is an uniprocessor AMD Thunderbird on an Asus A7V mobo. hm, it will not work on class 6 AMD systems. I'll fix this. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
Ingo Molnar wrote: > > the attached patch (against test9-pre7) is a cleaned up version Keir > Fraser's APIC-on-UP patch, and adds the enabling code of Keith Owens which > programs P6 performance counter 0 as an NMI. (i simplified the code alot - > there is no problem at all with getting NMIs from two sources, and it's > not necessary to make it configurable.) > > i'd like to hear about how this patch works for people - it works here on > SMP systems and on P6 systems. The watchdog is enabled unconditionally - > this should significantly help debugging lockups on UP systems as well! Hi Ingo et al, I've been giving the patch a try, however it hangs my machine during boot. Here's the important bits from console: Local APIC disabled by BIOS -- reenabling found and enabled local APIC! It then locks up in Calibrating delay loop... Machine is an uniprocessor AMD Thunderbird on an Asus A7V mobo. If you need additional info let me know. Cheers, Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Miles Lane wrote: > Cool. Is there anything else I need to know in order to the > UP-NMI-oopser effectively? It sounds like it'll just force an OOPS to > occur where a deadlock might have occured in the past. Is this > correct? If so, then using it is easy and I'll just see if I can get > my machines to crash. yes, it's merged into the IOAPIC based NMI oopser. Usage is completely automatic - it will oops if a hard lockup has occured. (ie. if a processor does not server interrupts for more than 5 seconds.) I have tested this by artificially causing kernel lockups, and it works here as expected. so it's a simple 'apply, compile, reboot' thing. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
Ingo Molnar wrote: > if SysRq works then this is a 'soft lockup', and if you want to debug this > then you should capture the EIP values from RightAlt+ScrLk output, thats > the place where it locks up. The UP-NMI-oopser will not help. > > Ingo Cool. Is there anything else I need to know in order to the UP-NMI-oopser effectively? It sounds like it'll just force an OOPS to occur where a deadlock might have occured in the past. Is this correct? If so, then using it is easy and I'll just see if I can get my machines to crash. Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
Ingo, Can you please outline exactly what testers with UP machines need to do to build, set up, enable and debug using this new code? I have an Athlon 750MHz machine and a Pentium II laptop that I use for testing and I'd like to exercise some of the experimental VM code. I have gotten system deadlocks on both of these machines, but I need some pointers in how best to extract useful debugging information from the deadlocked systems. Any help you can give in this regard would be much appreciated. I have used SysRq successfully, but I don't know how to use the information I am given to find the salient points. Thanks, Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] enabling APIC and NMI watchdog on UP systems
On Fri, 29 Sep 2000, Miles Lane wrote: > how best to extract useful debugging information from the deadlocked > systems. Any help you can give in this regard would be much > appreciated. I have used SysRq successfully, but I don't know how to > use the information I am given to find the salient points. if SysRq works then this is a 'soft lockup', and if you want to debug this then you should capture the EIP values from RightAlt+ScrLk output, thats the place where it locks up. The UP-NMI-oopser will not help. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] enabling APIC and NMI watchdog on UP systems
the attached patch (against test9-pre7) is a cleaned up version Keir
Fraser's APIC-on-UP patch, and adds the enabling code of Keith Owens which
programs P6 performance counter 0 as an NMI. (i simplified the code alot -
there is no problem at all with getting NMIs from two sources, and it's
not necessary to make it configurable.)
i'd like to hear about how this patch works for people - it works here on
SMP systems and on P6 systems. The watchdog is enabled unconditionally -
this should significantly help debugging lockups on UP systems as well!
(thanks Keir and Keith!)
Ingo
--- linux/include/asm-i386/apic.h.orig Thu Sep 28 05:18:49 2000
+++ linux/include/asm-i386/apic.h Thu Sep 28 05:29:14 2000
@@ -71,6 +71,7 @@
extern int verify_local_APIC (void);
extern void cache_APIC_registers (void);
extern void sync_Arb_IDs(void);
+extern int detect_init_APIC (void);
extern void setup_local_APIC (void);
extern void init_apic_mappings(void);
extern void smp_local_timer_interrupt(struct pt_regs * regs);
--- linux/include/asm-i386/msr.h.orig Thu Oct 7 10:17:09 1999
+++ linux/include/asm-i386/msr.hThu Sep 28 05:33:02 2000
@@ -30,3 +30,21 @@
: "=a" (low), "=d" (high) \
: "c" (counter))
+#define MCG_STATUS_MSR 0x17a
+#define MCG_CAP0x179
+#define MCG_CTL0x17b
+#define MC0_BASE 0x400
+#define MC0_CTL_OFFSET0x0
+#define MC0_STATUS_OFFSET 0x1
+#define MC0_ADDR_OFFSET 0x2
+#define MC0_MISC_OFFSET 0x3
+#define MC0_BANK_COUNT0x4
+#define DEBUGCTLMSR0x1d9
+#define LASTBRANCHFROMIP 0x1db
+#define LASTBRANCHTOIP 0x1dc
+#define LASTINTFROMIP 0x1dd
+#define LASTINTTOIP 0x1de
+#define PERFCTR00xc1
+#define PERFCTR10xc2
+#define EVNTSEL00x186
+#define EVNTSEL10x187
--- linux/include/asm-i386/processor.h.orig Thu Sep 28 06:39:06 2000
+++ linux/include/asm-i386/processor.h Thu Sep 28 06:39:27 2000
@@ -127,6 +127,8 @@
(boot_cpu_data.x86_capability & X86_FEATURE_FXSR)
#define cpu_has_xmm \
(boot_cpu_data.x86_capability & X86_FEATURE_XMM)
+#define cpu_has_apic \
+ (boot_cpu_data.x86_capability & X86_FEATURE_APIC)
extern char ignore_irq13;
--- linux/include/asm-i386/timex.h.orig Thu Sep 28 06:47:10 2000
+++ linux/include/asm-i386/timex.h Thu Sep 28 06:47:15 2000
@@ -45,4 +45,6 @@
#endif
}
+extern unsigned long cpu_khz;
+
#endif
--- linux/arch/i386/kernel/apic.c.orig Thu Sep 28 05:07:18 2000
+++ linux/arch/i386/kernel/apic.c Thu Sep 28 07:06:44 2000
@@ -84,15 +84,7 @@
void __init connect_bsp_APIC(void)
{
if (pic_mode) {
- /*
-* Do not trust the local APIC being empty at bootup.
-*/
- clear_local_APIC();
- /*
-* PIC mode, enable symmetric IO mode in the IMCR,
-* i.e. connect BSP's local APIC to INT and NMI lines.
-*/
- printk("leaving PIC mode, enabling symmetric IO mode.\n");
+ printk("leaving PIC mode, enabling APIC mode.\n");
outb(0x70, 0x22);
outb(0x01, 0x23);
}
@@ -107,7 +99,7 @@
* interrupts, including IPIs, won't work beyond
* this point! The only exception are INIT IPIs.
*/
- printk("disabling symmetric IO mode, entering PIC mode.\n");
+ printk("disabling APIC mode, entering PIC mode.\n");
outb(0x70, 0x22);
outb(0x00, 0x23);
}
@@ -201,12 +193,98 @@
| APIC_DM_INIT);
}
+/*
+ * Detect and enable local APICs on non-SMP boards.
+ * Original code written by Keir Fraser
+ */
+
+int detect_init_APIC (void)
+{
+ u32 h, l, dummy, features;
+
+ if (boot_cpu_data.x86 < 5) {
+ printk("No local APIC on pre-Pentium Intel processors\n");
+ return -1;
+ }
+
+ if (boot_cpu_data.x86 == 6) {
+ /*
+* Some BIOSes disable the local APIC in the APIC_BASE MSR.
+* This can only be done in software for PPro and above.
+*/
+ rdmsr(0x1b, l, h);
+ if (!(l & 0x800)) {
+ printk("Local APIC disabled by BIOS -- reenabling.\n");
+ l |= 0x800;
+ wrmsr(0x1b, l, h);
+
+ /*
+* The APIC feature bit should now be enabled
+* in `cpuid'
+*/
+ cpuid(1, &dummy, &dummy, &dummy, &features);
+ if (!(features & X86_FEATURE_APIC)) {
+ printk("Could not enable APIC!\n");
